Tracking Issue for `#![feature(c_size_t)]` (`std::os::raw::c_size_t`/`std::os::raw::c_ssize_t`)

[thomcc]

Feature gate: #![feature(c_size_t)].

This is a tracking issue for std::os::raw::{c_size_t, c_ssize_t}, which are guaranteed to be the same size as the underlying C size_t and ssize_t types from stddef.h.

Currently, on all targets, this is equivalent to usize and isize, however Rust has historically gone somewhat out of its way to avoid promising this. There are some targets with vaguely-planned support where this is not true (W65, used for SNES homebrew, for example)

Further reading here is available:

• https://rust-lang.zulipchat.com/#narrow/stream/136281-t-lang.2Fwg-unsafe-code-guidelines/topic/.60usize.60.20vs.20.60size_t.60
• https://internals.rust-lang.org/t/abi-discussion-for-w65/15092
• size_t vs usize rust-bindgen#1671

And probably more.

Public API

// std::os::raw

pub type c_size_t = usize;
pub type c_ssize_t = isize;

Steps / History

• Implementation: Add c_size_t and c_ssize_t to std::os::raw. #88340
• Final comment period (FCP)
• Stabilization PR

Unresolved Questions

• Do we want to instead guarantee usize and size_t are the same? See https://internals.rust-lang.org/t/pre-rfc-usize-is-not-size-t/15369
• Should this instead live in libcore somehow, given that probably libstd may never support platforms where this is not true. (This may not be true, since I imagine CHERI will support libstd)
• Do we need both the signed and unsigned version, given that size_t is more common in function signatures.
• ...

[joshtriplett]

Should this instead live in libcore somehow, given that probably libstd may never support platforms where this is not true.

At some point, I'd like to copy all the types from std::os::raw into core::ffi. core is compiled for the target system.

This particular proposal doesn't need to block on that, though; these should go into std::os::raw for now, and we can separately work on populating core::ffi.

[chorman0773]

Note that some types may not be the same on all targets for the same Architecture. For example (though I don't believe c_long exists), on x86_64-*-linux-gnu (or any Sys-V target for x86_64) c_long would be i64, but on x86_64-*-windows-msvc, it would be i32. I believe that, currently, everything in core, with the exception of atomic types, is gated on the architecture only. That may be something to consider.

[bjorn3]

Even atomic types are effectively gated on target cpu only and not the OS AFAICT. It just so happens that different target triples on the same architecture sometimes use a different target cpu with different levels of atomic support.

[chorman0773]

Don't atomic types on older arm targets depend on the os as well (since they require OS support to implement properly)?

…

On Thu, Aug 26, 2021 at 11:30 bjorn3 ***@***.***> wrote: Even atomic types are effectively gated on target cpu only and not the OS AFAICT. It just so happens that different target triples on the same architecture sometimes use a different target cpu. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#88345 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABGLD2ZELKNHU4MLYSPXWGTT6ZM25ANCNFSM5C2A7XKQ> .

[thomcc]

Modulo bugs, I believe platforms where OS support is required for atomic types are considered not to have atomic types by Rust.

(This seems to be getting off topic, perhaps)

[magicant]

ssize_t is actually not from stddef.h but from sys/types.h which is specific to Unix. On Windows, SSIZE_T is defined in BaseTsd.h.

[thomcc]

Nice catch. Do you want to submit a PR fixing the docs?

[magicant]

Yes, I'd love to. But I'm not sure if just fixing the doc for ssize_t is okay. Since ssize_t is platform-specific as I said, I'd rather suggest removing it from std::os::raw and possibly placing it under std::os::*::raw. If so:

• For Unix, std::os::unix::raw has been deprecated in favor of the libc crate. Maybe we should not add std::os::unix::raw::ssize_t now.
• For Windows, adding std::os::windows::raw::SSIZE_T would be okay, but adding only SSIZE_T among many types defined in BaseTsd.h might be kind of weird.
• For other platforms, I'm not sure if ssize_t is available in C at all.

What do you think?

[ChrisDenton]

Officially, isn't ptrdiff_t the signed counterpart to size_t?

[chorman0773]

Yes. ssize_t is only defined by POSIX, not ISO 9899. It also has a far different minimum required range (though for rust this is really a purely-pedantic argument), with ptrdiff_t's range being more usual for a signed integral type.(+/-(SIZE_MAX/2 -1)).

…

On Sat, Oct 30, 2021 at 10:07 Chris Denton ***@***.***> wrote: Officially, isn't ptrdiff_t the signed counterpart to size_t? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#88345 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABGLD236743EXNWWUTLY3XDUJQC27ANCNFSM5C2A7XKQ> .

[thomcc]

This probably should be changed to either expose ptrdiff_t instead of ssize_t, or to only expose size_t.

Either way, the future of this API depends a lot on https://internals.rust-lang.org/t/pre-rfc-usize-is-not-size-t/15369.

[thomcc]

This is hardly scientific, but to quantify my hunch that size_t is more common than ssize_t and ptrdiff_t in my installed headers, I did a check¹ to see if this is true. The numbers I got were:

Linux:

• 23793 hits for size_t
• 928 hits for ptrdiff_t
• 869 hits for ssize_t

Mac:

• 5761 hits for size_t
• 282 hits for ptrdiff_t
• 136 hits for ssize_t

Which probably means that size_t is the important thing here, and the signed version doesn't matter so much.

Footnotes

1. In the spirit of reproducibility, I ran the following command in fish-shell² to get these counts:

   rg -ce "$pattern" $include_dirs | string replace -r '^.*:' '' | paste -s -d+ - | bc
   

   Where:

   • $pattern is: \bsize_t\b, \bssize_t\b, or \bptrdiff_t\b
   • $include_dirs on linux was /usr/local/include and /usr/include.
   • $include_dirs on mac was /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include and /usr/local/include. These both might be system dependent in the following ways:
     • The first you can find it with something like xcrun --show-sdk-path --sdk macosx
     • And the second is where brew installs things (which seems to be different on new installs? Or maybe just on M1? IDK).
   ↩

2. fish-shell is required because string replace is easier for me than remembering how to use sed, but mostly becasue I had something very similar in my history.

   Sorry. If you tell me the equivalent sed incantation to delete everything prior to the last : in a line, I'll update this comment ↩