rust/library/std/src/os/raw, branch masterhttps://github.com/rust-lang/rust
http://git.dreamy.place/mirrors/rust/atom?h=master2024-05-20T15:13:31+00:00Remove Windows dependency on libc2024-05-20T15:13:31+00:00Ben Kimockkimockb@gmail.com2024-04-18T03:11:39+00:00urn:sha1:aa31281f2d8cb2b31e0396ad2dd7e3e8976ae25dRemove `#[cfg(all())]` workarounds from `c_char`2023-06-16T12:17:12+00:00Alex Macleodalex@macleod.io2023-06-10T12:07:04+00:00urn:sha1:b607a8a4af89c54d6cfcd633d9aabcc33e9c3502Provide C FFI types via core::ffi, not just in std2022-03-02T01:16:05+00:00Josh Triplettjosh@joshtriplett.org2022-03-01T22:46:41+00:00urn:sha1:335c9609c6340a9933915e717ee7a722bd9f81bc
The ability to interoperate with C code via FFI is not limited to crates
using std; this allows using these types without std.
The existing types in `std::os::raw` become type aliases for the ones in
`core::ffi`. This uses type aliases rather than re-exports, to allow the
std types to remain stable while the core types are unstable.
This also moves the currently unstable `NonZero_` variants and
`c_size_t`/`c_ssize_t`/`c_ptrdiff_t` types to `core::ffi`, while leaving
them unstable.
Work around Clippy false positive on `as c_char`2021-12-08T06:33:31+00:00David Tolnaydtolnay@gmail.com2021-12-08T06:33:31+00:00urn:sha1:4e8b91a920ce7bdb2284e39121bcda2294dc41a8Define c_char using cfg_if rather than repeating 40-line cfg2021-12-07T21:40:25+00:00David Tolnaydtolnay@gmail.com2021-12-07T21:32:03+00:00urn:sha1:db5a2ae6a401ec8154e7532b9ff3164cc6a29975Add riscv64gc-unknown-freebsd2021-11-27T06:24:18+00:00Tobias Kortkampt@tobik.me2021-11-27T06:23:55+00:00urn:sha1:47474f10558a473258510b0e5dea13d607a5d34cRe-add `std::os::raw::c_ssize_t`, with more accurate documentation2021-10-31T20:01:57+00:00Thom Chiovolonichiovolonit@gmail.com2021-10-31T20:01:57+00:00urn:sha1:8d19819781318c6ba24240af4b0038b692dd627fReplace `std::os::raw::c_ssize_t` with `std::os::raw::c_ptrdiff_t`2021-10-30T17:54:34+00:00Thom Chiovolonichiovolonit@gmail.com2021-10-30T17:54:34+00:00urn:sha1:d429d0df33ef0d726058fdc2611e78060703a7ecSuppress some cfg from being shown in the stdlib docs2021-10-05T16:15:29+00:00Wim Loomangit@nemo157.com2020-11-04T21:58:37+00:00urn:sha1:0031ce3a91d8e00691d09fcfca3164bc906f69afFix a technicality regarding the size of C's `char` type2021-09-20T06:19:13+00:00Nadja Reitzensteinme@dequbed.space2021-09-20T06:19:13+00:00urn:sha1:23c608f3a1b0cf09344f0e356610e59d8ee581ac
Specifically, ISO/IEC 9899:2018 — better known as "C18" — (and at least
C11, C99 and C89) do not specify the size of `byte` in bits.
Section 3.6 defines "byte" as "addressable unit of data storage" while
section 6.2.5 ("Types") only defines "char" as "large enough to store
any member of the basic execution set" giving it a lower bound of 7 bit
(since there are 96 characters in the basic execution set).
With section 6.5.3.4 paragraph 4 "When sizeof is applied to an operant
that has type char […] the result is 1" you could read this as the size
of `char` in bits being defined as exactly the same as the number of
bits in a byte but it's also valid to read that as an exception.
In general implementations take `char` as the smallest unit of
addressable memory, which for modern byte-addressed architectures is
overwhelmingly 8 bits to the point of this convention being completely
cemented into just about all of our software.
So is any of this actually relevant at all? I hope not. I sincerely hope
that this never, ever comes up.
But if for some reason a poor rustacean is having to interface with C
code running on a Cray X1 that in 2003 is still doing word-addressed
memory with 64-bit words and they trust the docs here blindly it will
blow up in her face. And I'll be truly sorry for her to have to deal
with … all of that.