-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tracking Issue for #![feature(c_size_t)]
(std::os::raw::c_size_t
/std::os::raw::c_ssize_t
)
#88345
Comments
At some point, I'd like to copy all the types from This particular proposal doesn't need to block on that, though; these should go into |
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 |
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. |
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>
.
|
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) |
|
Nice catch. Do you want to submit a PR fixing the docs? |
Yes, I'd love to. But I'm not sure if just fixing the doc for
What do you think? |
Officially, isn't |
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>
.
|
This probably should be changed to either expose 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. |
This is hardly scientific, but to quantify my hunch that Linux:
Mac:
Which probably means that size_t is the important thing here, and the signed version doesn't matter so much. Footnotes
|
…now-ptrdiff_t-is-my-best-friend, r=joshtriplett Replace `std::os::raw::c_ssize_t` with `std::os::raw::c_ptrdiff_t` The discussions in rust-lang#88345 brought up that `ssize_t` is not actually the signed index type defined in stddef.h, but instead it's `ptrdiff_t`. It seems pretty clear that the use of `ssize_t` here was a mistake on my part, and that if we're going to bother having a isize-alike for FFI in `std::os::raw`, it should be `ptrdiff_t` and not `ssize_t`. Anyway, both this and `c_size_t` are dubious in the face of the discussion in https://internals.rust-lang.org/t/pre-rfc-usize-is-not-size-t/15369, and any RFC/project-group/etc that handles those issues there should contend with these types in some manner, but that doesn't mean we shouldn't fix something wrong like this, even if it is unstable. All that said, `size_t` is *vastly* more common in function signatures than either `ssize_t` or `ptrdiff_t`, so I'm going to update the tracking issue's list of unresolved questions to note that perhaps we only want `c_size_t` — I mostly added the signed version for symmetry, rather than to meet a need. (Given this, I'm also fine with modifying this patch to instead remove `c_ssize_t` without a replacement) CC `@magicant` (who brought the issue up) CC `@chorman0773` (who has a significantly firmer grasp on the minutae of the C standard than I do) r? `@joshtriplett` (original reviewer, active in the discussions around this)
These are now in |
Just noting that these types are currently missing a reëxport into std. Even if presence of std means |
This CL provides mappings for most types under `core::ffi`, except for: * Types like `core::ffi::ptrdiff_t`, because they depend on an experimental feature: rust-lang/rust#88345 * `core::ffi::c_char` because of b/276931370 and because continuing translating `char` to `u8` reduces the amount of cascading changes in this CL (e.g. changes to `crubit/support/cc_std/string_view.rs`). Note that some other `clang/AST/BuiltinTypes.def` types like `char16_t` don't have an equivelent under `core::ffi`. This CL doesn't change how such types are handled (some of them are already covered by `rs_bindings_from_cc/type_map.cc`). PiperOrigin-RevId: 533279988
Would we be able to stabilize these or a subset? I know we have the Assuming they are always the same for our current supported targets, we just need to resolve that before adding targets where |
I don't believe the current implementation of Or otherwise, we need to document that on targets where usize and size_t are the same, implicit conversions are supported, but on other targets they are not. Or something else to that effect. However, in the past, we have not allowed even EXPLICIT conversions to be supported or not on a per-target basis. For example, there is no
|
This is true for the other |
Was this a historical accident or is this intentional though? IIRC it was intentional to not support the explicit conversions with |
I think the following table roughly captures current state:
I agree that changing
It does seem that Rust is missing IMO |
Changing them to structs would mean you can't initialize them from integer literals. |
I just want to make sure folks in this thread are aware of the Rust for Morello/CHERI Pre-RFC |
That doesn't seem like a big deal -- the For (hopefully rare?) cases when the C API expects things like buffer sizes to be provided directly, the
I've seen a lot of "Pre-RFC" threads in the forum that don't go anywhere. Is that a Pre-RFC in the sense that the Rust core language team is onboard with potentially changing the definition of If the definition of |
I don't really understand this point. In my experience it is a common idiom in C in general, not just Unix. An how is that related to |
|
Extremely pedantically speaking, it's somewhat possible to argue that On the other hand, C differentiates between Dialing back the pedantry. I don't think it's possible to stabilize
Without looking specifically at CHERI or W65, I think the most viable options are:
On CHERI, a " Footnotes
|
Having it be uN unconditionally will make my life easier, since I was planning to just have it expand to a macro called |
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 Csize_t
andssize_t
types fromstddef.h
.Currently, on all targets, this is equivalent to
usize
andisize
, 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:
And probably more.
Public API
Steps / History
c_size_t
andc_ssize_t
tostd::os::raw
. #88340Unresolved Questions
usize
andsize_t
are the same? See https://internals.rust-lang.org/t/pre-rfc-usize-is-not-size-t/15369libcore
somehow, given that probablylibstd
may never support platforms where this is not true. (This may not be true, since I imagine CHERI will support libstd)size_t
is more common in function signatures.The text was updated successfully, but these errors were encountered: