Skip to content

add a stucts-and-tuples chapter #31

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.

Sign up for GitHub

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 19 commits into from
Oct 25, 2018
Merged

add a stucts-and-tuples chapter #31

Changes from 1 commit
Commits
Show all changes
19 commits
Select commit Hold shift + click to select a range
c3a54f9
add a stucts-and-tuples chapter
nikomatsakis Sep 25, 2018
08062bd
add nits from eddyb
nikomatsakis Sep 26, 2018
eb951c2
correct typo
nikomatsakis Oct 11, 2018
d5a144b
strengthen to "subject to change between compilations"
nikomatsakis Oct 11, 2018
569338b
add note that packed adjusts alignment of the struct as a whole
nikomatsakis Oct 11, 2018
d96723f
`[T; 3]` and `(T, (T, T))` would have the same memory layout.
nikomatsakis Oct 11, 2018
4974192
rename ABI compatibility to "function call ABI compatibility"
nikomatsakis Oct 11, 2018
89a8a70
rework to call out details *not* relevant to layout
nikomatsakis Oct 11, 2018
c7d728e
make it clear that C17 etc are the "normative" spec for `#[repr(C)]`
nikomatsakis Oct 11, 2018
65f65f9
extract controversial unresolved questions
nikomatsakis Oct 11, 2018
fbafc2d
clarify wording
nikomatsakis Oct 11, 2018
fbf35bf
assign issues
nikomatsakis Oct 11, 2018
97622bc
generalize "input program" to "input to compiler"
nikomatsakis Oct 23, 2018
b0c86ea
be clearer about when reordering fields would be a breaking change
nikomatsakis Oct 23, 2018
f146fc4
rephrase "any" struct for clarity
nikomatsakis Oct 23, 2018
72f5db3
rework "default layout" to guarantee nothing for now
nikomatsakis Oct 23, 2018
17dab33
document zero-sized struct behavior
nikomatsakis Oct 23, 2018
a9223e2
say more about zero-sized things
nikomatsakis Oct 25, 2018
ece91f5
fix typo
nikomatsakis Oct 25, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 3 additions & 2 deletions reference/src/representation/structs-and-tuples.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -130,8 +130,9 @@ unsizing coercion may be applied.
### C-compatible layout ("repr C")

For structs tagged `#[repr(C)]`, the compiler will apply a C-like
layout scheme (see section 6.7.2.1 of the [C17 specification][C17] for
a detailed write-up):
layout scheme. See section 6.7.2.1 of the [C17 specification][C17] for
a detailed write-up of what such rules entail. For most platforms,
however, this means the following:
Copy link
Contributor

@gnzlbg gnzlbg Oct 11, 2018 •
edited
Loading

Choose a reason for hiding this comment

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

Maybe we should just go one step further here and just state that the "most recent" C specification applies. It would be a pain to have to update this every N years, history has shown that the newer C specs are backwards compatible with the old ones (e.g. the C99, C11, and C17 specs have never introduced breaking changes here - they just have defined behavior that was undefined before), and we probably want to be as compatible as possible with C anyways which means we have to follow the latest spec.

This kinds of ties Rust with the C spec, but this is already pretty much the case, not only for platform support, but some newer C proposals like N2289 - Zero overhead failure should definetely allow using Rust's Option and Result properly as error handling mechanisms in C FFI. So whether we like it or not, Rust is already a stakeholder in the C standardization process, and we should be sending someone to their meetings to represent Rust's interests in the ISO C standard evolution, and that would include layout guarantees for repr(C) types. We don't want any changes to the C language to make it impossible for Rust to target C via FFI.


[C17]: http://www.open-std.org/jtc1/sc22/wg14/www/abq/c17_updated_proposed_fdis.pdf

Expand Down