os::mkdir and friends should maybe not take u32

[brson]

These are Rust functions, not C.

[sammykim]

What should it take instead of c_int?

[brson]

Here's some discussion from IRC

22:05 < strcat> brson: well, ideally not an enum
22:05 <@brson> yichoi: graydon could disagree though. I'm not sure what his vision for that module is and 
               he usually likes less abstraction than I
22:05 < strcat> we just need a flag type with | overloaded
22:05 < strcat> and some constants
22:05 < strcat> casting to an int to OR them would be annoying

@thestinger has some opinions

[yichoi]

@thestinger refered
https://github.com/thestinger/rust-magic/commit/16a4fe0505f3c35cd4fa8fb051a5e6f396d2b2eb

[thestinger]

I think structs are better for flags, because you're not restricted to the pre-defined variants. It wouldn't be safe to OR enum variants together unless you added a variant for each combination (match assumes it knows all of the variants, and so do the loads in the IR now).

It's much nicer to be able to do let base = FlagA | FlagC | FlagE and then call a function with base | FlagB than building up vectors.

[brson]

We might want to use @nikomatsakis' EnumSet: nikomatsakis@75df9af#L10L-1

[emberian]

Visiting for triage; still relevant. EnumSet still a viable solution.

[sammykim]

It's still taking c_int and remains an issue.

[martindemello]

I can take a shot at this. Is EnumSet still the way to go? And if so, would it need to be moved into libstd first?

[sanxiyn]

#8054 moved EnumSet to libextra.

[richo]

I'm interested in working on this. It looks like EnumSet has landed in core (Based on the hits for git grep EnumSet in the main repo).

Is there anything special I should know before I dive in? (Found this as a result of digging through issues tagged easy to play with)

[richo]

I did some preliminary work to allow the use of EnumSet in std here: #13196

I'll tentatively start work on porting the permission flags, and then rebase when I found out the fate of that PR.