Detail layout of repr(C) unions#160
Conversation
Co-Authored-By: Ralf Jung <post@ralfj.de>
Co-Authored-By: Ralf Jung <post@ralfj.de>
…zero-size is not that common
…es into reprc_unions
reference/src/layout/unions.md
Outdated
| # } | ||
| ``` | ||
|
|
||
| **C++ compatibility hazard**: C++ does, in general, give a size of 1 to empty |
There was a problem hiding this comment.
Should we maybe say "struct with no field"? "empty" in Rust means something else than in C++.
There was a problem hiding this comment.
Can we add a link somewhere to the section about zero-sized types in structs-and-tuples.md? That section goes into a lot more detail, e.g.
- explicitly stating that empty structs are illegal in C
- mentioning
[[no_unique_address]] - differentiating between structs with no fields and structs with fields of zero size
There's no need to repeat all that here, but a link would be helpful.
There was a problem hiding this comment.
(Perhaps also mention that Rust unions can't have zero fields.)
There was a problem hiding this comment.
The text now uses "struct with no fields" and refers and links to the structs chapter for details.
There was a problem hiding this comment.
Some of your commits seem to have been lost? Like, "Link to struct chapter" just is not in this PR any more.
There was a problem hiding this comment.
That might not have been intended. I merged the "suggestion changes" and that had conflicts so I had to force push :/
There was a problem hiding this comment.
Force-push shouldn't be needed after merging...? Weird.
There was a problem hiding this comment.
I screw up. I need to learn how to "pull" changes to my branch locally and rebase them without spurious merge commits when my local branch has other changes :/
Co-Authored-By: Ralf Jung <post@ralfj.de>
…es into reprc_unions
|
Other than this final issue about empty structs, I have one more remark. I felt it is eaiser to just open a PR against your PR for this: gnzlbg#1 |
mention size-filling padding
RalfJung
left a comment
There was a problem hiding this comment.
I think we are finally there. :) Thanks for prevailing!
Documents the behavior described in #156 .