You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
An object with the boolean type has a size and alignment
of 1 each. The value false has the bit pattern 0x00 and the value true has the bit pattern 0x01. It is undefined behavior for an object with the boolean type
to have any other bit pattern.
warning: `extern` fn uses type `Improper`, which is not FFI-safe
--> <source>:2:35
|
2 | pub extern "C" fn bad(_: bool, _:Improper){}
| ^^^^^^^^ not FFI-safe
|
= note: `#[warn(improper_ctypes_definitions)]` on by default
= help: consider adding a `#[repr(C)]` or `#[repr(transparent)]` attribute to this struct
= note: this struct has unspecified layout
note: the type is defined here
--> <source>:1:1
|
1 | pub struct Improper;
| ^^^^^^^^^^^^^^^^^^^^
warning:1warning emitted
The reference states that bool has the same layout as u8 and can only take on the "usual" bitpatterns. OTOH, The improper ctypes lints seem to believe that bool is FFI-safe, by omission, which is further underscored in the UGC draft: https://rust-lang.github.io/unsafe-code-guidelines/layout/scalars.html#bool, which ties it to _Bool; C makes ~no guarantees about the layout of this type, although papers have been published in the past to try to nail down a bit representation. (Personally, such a proposal seems as unlikely as nullptr being guaranteed to be all-zeroes, so I wouldn't count on it.)
Discussion on a somewhat old issue seems to indicate we are not sure how we feel about this, so I'd lean towards weakening the reference's assertion.
The text was updated successfully, but these errors were encountered:
The decision to make bool FFI-safe for the currently supported platforms has been made consciously (though I don't have a link to the discussion wherein the decision has ultimately been made.) Both this (for the current platforms) and the size/bit-pattern as documented in the reference are part of the stability guarantee and so neither will change. UCG is not a normative document, as far as I know, and so the text there can be freely adjusted as the landscape changes.
As far as our options go, if an ABI with a different _Bool turns up the FFI-unsafe lint could be enabled for the affected triples.
The following seem inconsistent:
The reference states that
bool
has the same layout asu8
and can only take on the "usual" bitpatterns. OTOH, The improper ctypes lints seem to believe thatbool
is FFI-safe, by omission, which is further underscored in the UGC draft: https://rust-lang.github.io/unsafe-code-guidelines/layout/scalars.html#bool, which ties it to_Bool
; C makes ~no guarantees about the layout of this type, although papers have been published in the past to try to nail down a bit representation. (Personally, such a proposal seems as unlikely as nullptr being guaranteed to be all-zeroes, so I wouldn't count on it.)Discussion on a somewhat old issue seems to indicate we are not sure how we feel about this, so I'd lean towards weakening the reference's assertion.
The text was updated successfully, but these errors were encountered: