Skip to content
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

Is bool FFI-safe? #95184

Open
mcy opened this issue Mar 21, 2022 · 2 comments
Open

Is bool FFI-safe? #95184

mcy opened this issue Mar 21, 2022 · 2 comments
Labels
A-ABI Area: Concerning the application binary interface (ABI) A-FFI Area: Foreign function interface (FFI)

Comments

@mcy
Copy link
Contributor

mcy commented Mar 21, 2022

The following seem inconsistent:

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.

-- https://doc.rust-lang.org/reference/types/boolean.html#boolean-type

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: 1 warning 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.

@nagisa
Copy link
Member

nagisa commented Mar 23, 2022

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.

@nagisa
Copy link
Member

nagisa commented Mar 23, 2022

Relevant PRs: #46176, #46156.

@workingjubilee workingjubilee added the A-FFI Area: Foreign function interface (FFI) label Mar 23, 2022
@workingjubilee workingjubilee added the A-ABI Area: Concerning the application binary interface (ABI) label Jul 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-ABI Area: Concerning the application binary interface (ABI) A-FFI Area: Foreign function interface (FFI)
Projects
None yet
Development

No branches or pull requests

3 participants