Move std::os::raw to libcore?

[SimonSapin]

I’m currently playing "embedded" with hardware (ARM Cortex-M CPU with 64 KB RAM). I’m using #![no_std] (there’s no operating system) and FFI to use C and C++ device drivers.

For bindings I’d like to use std::os::raw::c_long and other types in that module. But this module is not available in libcore. Is there a reason for this? If not, I’ll submit a PR to move it (and of course re-export it at its current location).

[steveklabnik]

Historically, my understanding is that libcore is not supposed to contain anything os-specific. I think.

[SimonSapin]

My understanding is that it doesn’t depend on API or other things provided at run-time by an OS, but that doesn’t mean it can’t have things that compile differently based on the target/platform. src/libcore already contains cfg attributes or macros for:

• target_pointer_width
• target_arch
• sse2
• target_endian
• target_has_atomic

[alexcrichton]

Yes historically we have not done this because of what @steveklabnik said. These types are OS-specific, not architecture specific, which I believe the other flags you're mentioning @SimonSapin are.

This is also why the libc crate has a #![no_std] mode, for using these types without libstd.

[SimonSapin]

This is also why the libc crate has a #![no_std] mode, for using these types without libstd.

Ohh, I didn’t know about that. Thanks!

[SimonSapin]

Well, current libc doesn’t build on a custom thumbv7em-none-eabi target. (4 thousands and some lines of compile errors: rust-lang/libc#375)

Regardless, I don’t understand why having cfg(windows) conditional compilation in libcore is so much worse than cfg(sse2), long as libcore doesn’t run-time-depend on things from the OS.

[retep998]

Regarding #[cfg(windows)], winapi defines the C types itself https://github.com/retep998/winapi-rs/blob/dev/src/lib.rs#L35. It only relies on std for c_void if that feature is enabled.

I personally don't hold an opinion either way on whether this sort of stuff should be in libcore. If it does get added to libcore, just be very careful to ensure that they are defined correctly for every single obscure platform that libcore can be used on.

[parched]

These are target specific, not OS specific aren't they? And there's other target specific stuff in core, isn't there? I think it would be useful to interface easily with C using no_std.

[Amanieu]

Not exactly. For example on x86_64, c_long is 32 bits on Windows and 64 bits everywhere else.

[Amanieu]

Moving these types into core without breaking compatibility with the libc crate (especially for the c_void type) is going to be challenging. I think a better solution would be to move them into a separate no_std crate called ctypes (name subject to the usual bikeshedding). Unlike libc, ctypes does not link to the C library and only provides type definitions and constants. The libc crate will then be modified to re-export the types from ctypes.

[parched]

Not exactly. For example on x86_64, c_long is 32 bits on Windows and 64 bits everywhere else.

Yes, but I would say it's because they are different "targets" or ABIs. It's not like they are consistent on an OS, i.e., c_long isn't always 32 bits on Linux irrespective of the target.

[bluss]

Prior discussion: https://internals.rust-lang.org/t/solve-std-os-raw-c-void/3268/