Skip to content

Be more explicit about the layout guarantees of integer and floating-point types #98

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

Merged
merged 11 commits into from
Apr 11, 2019

Conversation

gnzlbg
Copy link
Contributor

@gnzlbg gnzlbg commented Mar 14, 2019

I was going through issue #9 and there it was mentioned that we wanted to guarantee that the fixed-width integer (and floating-point) types can interoperate with C's fixed-width integer and floating point types. Going through the text this felt implied, in particular, because C's fixed-width integer types guarantee some things that were not mentioned in the text (e.g. 2's complement for signed integers).

This PR attempts to call this out more explicitly. In particular in #9 there was a question about whether one should use, e.g., libc::uint8_t in C FFI or whether using u8 is ok. This PR explicitly mentions that using u8 is ok.

@gnzlbg gnzlbg force-pushed the fixed_width_int_c_ffi branch from 393ef3e to b6d30c5 Compare March 15, 2019 10:27
@gnzlbg gnzlbg force-pushed the fixed_width_int_c_ffi branch from bf25d08 to 5f54e61 Compare March 16, 2019 09:38

The layout of `usize` determine the following:

- the maximum size of Rust values is _implementation-defined_, but can at most
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just noting that we use "value" to mean a very particular thing here -- the same thing that C calls "object", from what I can tell. Also see #40.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A relatively easy way to avoid that issue while also being less jargon-intense would be to talk about the sizes of allocations. Just risks people thinking about heap allocation to the exclusion of all other kinds.

Copy link
Contributor Author

@gnzlbg gnzlbg Mar 16, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@RalfJung once #40 is merged we should probably start linking these terms to their definitions (EDIT: i've added emphasis to the "values", but that doesn't help much).

@rkruppe with #40 we might be talking about the size of "places", which would remove the ambiguity with heap allocations, but it is still jargon heavy.

@gnzlbg gnzlbg merged commit a9809bb into rust-lang:master Apr 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants