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

Terminology around layout, ABI, representation, and bit validity #304

Closed
joshlf opened this issue Sep 1, 2021 · 8 comments · Fixed by #457
Closed

Terminology around layout, ABI, representation, and bit validity #304

joshlf opened this issue Sep 1, 2021 · 8 comments · Fixed by #457
Labels
A-layout Topic: Related to data structure layout (`#[repr]`) C-terminology Category: Discussing terminology -- which term to use, how to define it, adding it to the glossary S-not-opsem Despite being in this repo, this is not primarily a T-opsem question

Comments

@joshlf
Copy link

joshlf commented Sep 1, 2021

I'm writing the docs for the following type:

#[repr(packed)]
pub struct Unalign<T>(T);

I'd like to explain in the docs that the layout/ABI/representation/bit validity/whatever is the same as that of T with the exception of alignment, but I'm not sure what terminology to use. A few observations:

  • Per the Rust reference, "layout" refers at least to size, alignment, and field offsets
  • In some docs - such as those for MaybeUninit - the phrase "ABI" is also used
  • The UCG WG has used the phrase "validity" to refer to the set of allowed bit patterns for a type
  • The phrase "representation" seems to be fairly consistently used to refer to the repr attribute (whether or not the attribute is present and, if present, what values are given)

My questions are:

  • Does "layout" also encompass a type's bit validity?
    • If not, what phrase refers to a type's bit validity? Do we just have to say "layout and bit validity" if we want to encompass everything?
  • What does the phrase "ABI" mean?

As a meta point, it seems like the terminology has been somewhat standardized over time as folks have gravitated towards a common set of terms, but there's still some disagreement (e.g., I haven't seen "ABI" used in most places, but it does show up). It would be good to decide on a standard set of terms, and to standardize their usage across the docs.

@Lokathor
Copy link
Contributor

Lokathor commented Sep 1, 2021

I believe that ABI refers to, at least, how the data is passed between functions.

It might also mean other things, but it at least means that much.

@joshlf
Copy link
Author

joshlf commented Sep 1, 2021

how the data is passed between data

Passed between functions?

@Lokathor
Copy link
Contributor

Lokathor commented Sep 1, 2021

Yes. When data is passed between functions both functions must agree where the caller will put the data for the callee's arguments, and also where the callee will leave the data for the caller's return value.

EDIT: oh i see, i made a typo at first. sorry, fixed

@RalfJung
Copy link
Member

RalfJung commented Sep 4, 2021

Yeah, sadly we never reached consensus for what exactly is part of "layout" and "ABI"... also see #122.

I honestly don't even really care which terms we end up using, as long as we have names for all the relevant things and we can all agree on using the same names. :)

@joshlf
Copy link
Author

joshlf commented Feb 7, 2022

Assuming one were to come up with a standard set of terms, what would the process be like for getting that accepted as official? Is it just a matter of getting sign-off and merging a doc somewhere, or would deeper surgery be required in order to get all docs up to standard before such a doc was merged?

@RalfJung
Copy link
Member

RalfJung commented Feb 7, 2022

I would think it would start by updating the glossary and other documents in this repository. If we find something that works well for this, then one could start to figure out if there are conflicts with any of the official documentation, and start talking to the relevant teams to figure out how to update their terminology.

@scottmcm
Copy link
Member

scottmcm commented Feb 8, 2022

We have Layout::from_size_align on stable, so that nudges the definition in that direction, at least.

Then ABI + invariants are additional atop that, I guess.

@Lokathor
Copy link
Contributor

Lokathor commented Feb 8, 2022

Yeah but unfortunately that Layout type doesn't tell you field placement, which is the whole big thing people normally want to know about for their structs.

@JakobDegen JakobDegen added A-layout Topic: Related to data structure layout (`#[repr]`) C-terminology Category: Discussing terminology -- which term to use, how to define it, adding it to the glossary S-not-opsem Despite being in this repo, this is not primarily a T-opsem question labels Jul 25, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-layout Topic: Related to data structure layout (`#[repr]`) C-terminology Category: Discussing terminology -- which term to use, how to define it, adding it to the glossary S-not-opsem Despite being in this repo, this is not primarily a T-opsem question
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants