Stream: t-lang/wg-unsafe-code-guidelines

Topic: #[repr(C)] unions safer than #[repr(Rust)] unions?

briansmith (Dec 09 2018 at 02:21, on Zulip): says "Inactive fields can be accessed as well (using the same syntax) if they are sufficiently layout compatible" but the RFC says that reading a (a part of a) member that wasn't the last one written to is undefined behavior. I had already written code that assumes that the Rust reference is correct. I went back and added #[repr(C)] to my unions to make them safer as there seems to be some dispute about whether #[repr(C)] guarantees more than #[repr(Rust)] here. What's the current status?

Nicole Mazzuca (Dec 09 2018 at 03:50, on Zulip):

#[repr(C)] won't guarantee anything more than #[repr(Rust)]. I think that they just defined it in the transition from RFC to language?

Nicole Mazzuca (Dec 09 2018 at 03:50, on Zulip):

basically, C rules, not C++ rules

briansmith (Dec 09 2018 at 06:31, on Zulip):

I think that has to be the case, because it would be very easy to accidentally get undefined behavior by forgetting the #[repr(C)]; I've done it myself already. Plus people don't expect "C" to be safer than "Rust"; it'd be counter-intuitive.

RalfJ (Dec 09 2018 at 09:40, on Zulip):

Inactive fields

the plan is for Rust to not have any notion of "active/inactive union fields". Instead, every access just interprets the data stored in memory at the type used for the access. basically, unions field access is sugar for transmute, no more.

RalfJ (Dec 09 2018 at 09:41, on Zulip):

(well, my plan anyway, but it seems like most people agree)

RalfJ (Dec 09 2018 at 09:43, on Zulip):

wow there is some strange structure in the reference... there is items/unions and types/union?

Matthew Jasper (Dec 09 2018 at 10:31, on Zulip):

There are types that aren't items and items that aren't types, so there has to be a section for both of them. I think that the plan is to merge the struct, enumeration and union type pages and put most of the information on the item pages.

gnzlbg (Dec 09 2018 at 11:17, on Zulip):

@RalfJ a C++ reference is not a “lawyer object”. Pretty unfortunate that one has to be aware of that when using C++ or reading the standard.

RalfJ (Dec 09 2018 at 13:09, on Zulip):

@gnzlbg not sure what this is a reply to?

RalfJ (Dec 09 2018 at 13:09, on Zulip):

I was talking about the Rust reference above

RalfJ (Dec 09 2018 at 13:34, on Zulip):

sent a PR to remove the notion of an "active field":

gnzlbg (Dec 09 2018 at 13:47, on Zulip):

Oh I meant to reply to the nomenclature (place, ..) topic - guess I need to figure out how the mobile app works.

briansmith (Dec 09 2018 at 22:53, on Zulip):


RalfJ (Dec 10 2018 at 08:00, on Zulip):

people don't expect "C" to be safer than "Rust"; it'd be counter-intuitive

I disagree; for unsafe code that plays games with struct layout, for example, repr(C) is "safer" (and required)

briansmith (Dec 10 2018 at 18:00, on Zulip):

@RalfJ I understand that repr(C) actually is safer than repr(Rust). However, that is almost definitely surprising to people who don't think about these things as much as we do.

Last update: Jul 03 2020 at 17:35UTC