Member

This doesn't really clarify anything, the term "storage" is really ambiguous and the wording of "unnamed fields do not occupy any storage" implies that unnamed fields don't take up any space whatsoever, which isn't correct

Author

Contributor

implies that unnamed fields don't take up any space whatsoever, which isn't correct

That is the intended reading. Unnamed fields only affect the layout but are not themselves members of the struct. See also the equivalent notation for unnamed fields using attributes in the RFC.

In C++, unnamed fields are described as "not being members" of their surrounding struct. In C the language is not as simple but this difference is hopefully irrelevant in practice.

Member

The space still exists though, those bits don't just disappear right?

Author

Contributor

I do not know what you mean by "the space exists". Space between fields in structs "exists" but the behavior of that space is not defined in great detail as far as I can tell.

Contributor

Right, that's the problem. You have to say what's going on with that. Even if C doesn't, in Rust we care about those sorts of things.

Author

Contributor

This RFC is not the place to resolve these issues.

Author

Contributor

This issue seems to be the most relevant: rust-lang/unsafe-code-guidelines#156

Contributor

You don't have to fix all of uninit memory for rust, you just have to say something about the spare bits in this one case.

It can be "the bits are unspecified" (my pick), or "the bits are niche", or "the bits are always zero", or whatever, but the RFC shouldn't leave this unanswered.

Author

Contributor

If you get such language merged into the language reference for padding bits in general, then I will refer to it. Otherwise I do not see why this RFC should document the state of padding bits of

#[repr(C)]
struct X {
	a: u8,
	#[bitfield(8)] _: u8,
	b: u16,
}

when the state of padding bits of

#[repr(C)]
struct X {
	a: u8,
	b: u16,
}

is not documented.

Member

Yah, this RFC is in a position in which it can entirely bypass the issues of previous code with uninit memory since it can simply declare what the state of "padding bits" should be, which should almost definitely be unspecified

Member

We could, potentially, allow taking the address of a bitfield if and only if it's aligned to a byte boundary. But I don't think we should. So, this seems fine.

Member

Thank you for specifying this behavior precisely.

Member

I agree that this needs clarification.

Member

I'm wary of the "in every way like padding bits" phrasing because it brings to mind undefined padding bytes (a la this comment)

Author

Contributor

I've rewritten the reference section to make it clear that _ bit-fields are not fields.

Member

Please note that we already have a concept of unnamed fields of struct or union type, which have a different semantic. For clarity, I'd suggest:

Or, for that matter, perhaps directly call it a padding bit-field.

Member

I'd prefer not to leave the behavior quite this unspecified. I would prefer to have it explicitly specified that a store to a bitfield is permitted to be combined with other stores to bitfields or other fields in a single operation, but that the operation will not be performed via a wider write than a single machine word that affects fields other than those being written, unless the entire structure is actually being written.

People do use bitfields for flags within larger structures, where other parts of the structure might be concurrently accessed while under a lock, and they assume that a write to one of those bitfields will not overwrite a lock-protected value. We should be precise enough that people know how they can avoid that.

Author

Contributor

People do use bitfields for flags within larger structures, where other parts of the structure might be concurrently accessed while under a lock

You're right, I didn't take into account that other fields might have interior mutability. I'll replace this by the usual language:

The memory locations of two different fields within a struct do not overlap if

• at least one of them is not a bit-field or
• they are separated, in declaration order, by at least one field
  • that is not a bit-field or
  • that is a bit-field with width 0.

"Memory location" is the language used by C to determine when two unsynchronized concurrent accesses are well-defined.

Member

That sounds reasonable to me, assuming that it includes associated text explaining what can and can't be done in the same memory operation.

Author

Contributor

I've chosen a somewhat different formulation to avoid pulling in the C memory model:

When a bit-field field is accessed, the abstract machine may also access
adjacent bit-field fields but not fields that are separated from the field by a
StructBodyElement that is not a bit-field field. (Note: This paragraph restricts
the kinds of loads and stores the compiler can perform when accessing a
bit-field. This paragraph does not need to be specially advertised to users as
the inability to take references to bit-field fields makes it impossible to
access adjacent bit-field fields in otherwise sound code.)

Member

I agree both that this might be a good long-term solution (and bit-sized types would be useful for other purposes), and that this should not block the implementation of bitfields.

If, in the future, we add bit-sized types, we can specify how to put them in a repr(C) struct and have them behave like a bitfield. That should not stop us from providing the most straightforward implementation of bitfields without introducing bit-sized types.

Member

We should specify, explicitly, that the behavior on MSVC targets must match that of MSVC.

(We don't, today, need to provide a means of controlling the ms_struct flag. We may need to eventually, though.)

Author

Contributor

@retep998 Please give your opinion on which language, if any, should be added to this RFC and which language should be included in the reference.

Member

Please specify the behavior of bitfield(0) in this RFC. In general, I don't have any objection to defining this feature in terms of C-compatible bitfield types. However, I'd like to have a self-contained explanation for bitfield(0).

Author

Contributor

I do not think the behavior of zero-width bit fields is specified enough to make this worth it. I think the most than can be said is that a zero-width bit field causes the storage unit allocated for the next bit field to be aligned at least to the next 8-bit boundary (the next byte). But this is probably not what you had in mind.

Member

Why don't we just prohibit the use of pub (or any visibility) on _ fields?

Author

Contributor

I want _ to appear in rustdoc if I write a sys-wrapper for a C API that uses unnamed bit fields. On the other hand, sometimes such wrappers are supposed to have private fields. How would rustdoc decide if it should show the field or not?

With visibility modifiers this is not a problem and the author can also add doc comments if necessary. E.g. if the original C struct documents that field.

Member

Author

Contributor

Assume that structs could have associated types:

struct X {
	type MyType = i32;
	field1: u8,
	field2: u16,
}

Does the statement

However, the contents of AssociatedTypes are unspecified, allowing reading from and transmuting to/from structs with associated types without incurring undefined behavior.

make sense to you?

Contributor

Of course not, because types don't hold values.

Author

Contributor

AssociatedType is not a type. It's a non-terminal in the Rust grammar. It's a part of the syntax, and syntax does not exist at runtime. As such, they don't have contents except in the syntax sense.

Contributor

If you agree they have no content, then I don't understand what you're getting at.

Contributor

Kixiron said what I was trying to say.

Essentially, if the spare bits are defined to be anything other than "initialized but unspecified" then I can make a more safe version of bitfields, by hand, today, than this RFC would allow for.

Member

I think I see why this was initially confusing.

It'd be conceptually straightforward to interpret the unnamed fields as "padding", except for the bitfield(0) case. But then it's necessary to specify the behavior of those fields.

You're proposing, instead, that unnamed "fields" (including bitfield(0) fields) don't define padding themselves; rather, they define the positioning of bitfields, and the positioning of bitfields within a larger structure defines padding. And that padding behaves like any other padding.

I think this explanation could use further in-RFC clarification to make the approach more obvious, and to separate the concept of "unnamed 'fields' defining where fields are placed" from "padding defined by where fields are placed". But given some additional explanation in that area, I don't object to the idea of making this RFC entirely orthogonal to any definition of padding..

I do think that many practical uses of bitfields would benefit from some additional definition of padding. But I also know that defining the behavior of padding is a much more controversial topic, and I don't want to see bitfields held up behind that topic.

Author

Contributor

You're proposing, instead, that unnamed "fields" (including bitfield(0) fields) don't define padding themselves; rather, they define the positioning of bitfields, and the positioning of bitfields within a larger structure defines padding.

No I think that's too narrow. Unnamed "fields" also affect the positioning of regular fields and the overall alignment. They are layout modifiers like repr(align) except that they are written inside the struct body.

Member

And, reading further into the updated description, I think the new approach of not calling them "fields" provides the necessary clarity. (The distinction of "bit-field fields" is perhaps a little awkward, but nonetheless clear.)

Contributor

This is an extremely small point that I didn't know that affects the proposal a lot. How does it affect it?

This to me is an important aspect that justifies using this method instead of Zig's.

Shouldn't just be a footnote.

Author

Contributor

I believe the first motivating example should make this clear.

Contributor

Not really. It doesn't do that great a job of providing motivation beyond "this is how it affects C."

Why not just require additional alignment attributes instead of using different types for bitfields? I feel like these should be weighed as additional options.

Compatibility with C definitions could definitely be enough to justify it, but it should be explained better in the RFC rather than assuming every reader knows what it means and how it affects their code.

Author

Contributor

It doesn't do that great a job of providing motivation beyond "this is how it affects C."

Being compatible with C without having to write target-specific code is, in fact, the motivation of the RFC and this is made pretty clear. Please read the discussion of the original RFC where at least 50% of the over 90 comments were trying to argue that what we actually want is arbitrarily sized integers and custom struct layouts.