Replies: 1 comment 4 replies
-
|
I don't think we can do this exactly; It is possible that something nicer exists though, worth asking around on Zulip if you are interested. |
Beta Was this translation helpful? Give feedback.
-
|
This also relates to a problem that a lot of our flags have; usually flags are an |
Beta Was this translation helpful? Give feedback.
-
|
Thx @tgross35, I actually think #[cfg(target_os = "linux")]
type mode_t = u32;
#[cfg(target_os = "redox")]
type mode_t = i32;
#[repr(transparent)]
struct Mode(mode_t);
// file in src/unix
impl crate::Mode {
const FLAG1 = Mode(0x1);
}
// file in src/unix/linux_like
impl crate::Mode {
const FLAG2 = Mode(0x2);
}I agree that we can't do much if a function requires any type other than Note that I suspect Nix only does this because they would love to offload it to libc but can't. If libc starts doing it, this will make everyone's live much easier, esp because it can support all OS-es libc supports. |
Beta Was this translation helpful? Give feedback.
-
|
P.S. The main issue with wrapping this functionality is that whatever wraps it must duplicate all the conditional logic that libc already has - so maintaining it seems like a huge and un-needed burden. |
Beta Was this translation helpful? Give feedback.
-
|
P.P.S. I got a good answer from bitflags about it at bitflags/bitflags#441, so clearly bitflags won't work, but we can easily do much simpler libc-focused macro to generate what we need, and even have it in a backwards compatible way. This macro would expand to what we have in libc at the moment, as well as adds same constants to the libc_bitflags! {
Mode: mode_t => [
// Note that these are identical to what libc has now, just moved inside the macro
const S_IEXEC = crate::S_IXUSR;
const S_IWRITE = crate::S_IWUSR;
const S_IREAD = crate::S_IRUSR;
]
} |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
libc has several bitflag type aliases, e.g.
mode_t- which are currently not strongly typed, thus require users to constant deal with casting, and may cause some subtle bugs.Would it make sense to introduce a nicer layer of abstraction over these fields using bitflags or similar crate? This will also help hiding the size of the actual OS-specific field - e.g.
mode_tis u32 on most platforms, but it is i32 on Redox and u16 on some other OSes.see also uutils/coreutils#7751
Beta Was this translation helpful? Give feedback.
All reactions