CWG3209 [basic.compound] Pointer-interconvertibility with bit-fields

Full name of submitter (unless configured in github; will be published with the issue): Jay Ghiron

Reference (section label): [basic.compound]/6.3

Issue description:

struct{int x:2;}x;

According to this, x and x.x are pointer-interconvertible. That is surely not intended.

You can't even form a pointer to the bit-field, so why does this matter?

You can't even form a pointer to the bit-field, so why does this matter?

[expr.static.cast]/12 combined with this would mean that reinterpret_cast<int*>(&x) should be a pointer to the bit-field, it is pointer-interconvertible with the bit-field member and the type of the bit-field is similar to int.

Maybe the right fix is to amend [basic.compound] so that "pointer values" can't point to bit-field objects. This would moot the question, i think.

In my opinion, the rule from [class.bit#3] refutes the receipt of pointers or references to bit-fields already in the existing text of the C++ standard.

the type of the bit-field is similar to int.

Doesn't [class.bit#1] refute this perception of the provisions of the standard?

the bit-field semantic property is not part of the type of the class member.

I also believe that the standard's [class.mem#general-31] provision makes it impossible to treat a standard-layout class object and its first member (if it is a bit-field) as pointer-interconvertible
(since the [basic.compound]/6.3 rule relies on the provisions of [class.mem])

I think we can add an additional note for [basic.compound]/6:

[Note 7: A standard-layout class object and its first non-static data member, which is a bit field, are not pointer-interconvertible because they are not guaranteed to have the same address ([class.mem.general]). — end note]

I also believe that the standard's [class.mem#general-31] provision makes it impossible to treat a standard-layout class object and its first member (if it is a bit-field) as pointer-interconvertible (since the [basic.compound]/6.3 rule relies on the provisions of [class.mem])

I don't follow how you arrived at this conclusion. "pointer-interconvertible", as currently defined, doesn't depend on the address of the corresponding objects to be the same.

As for reinterpret_cast<int*>(&x) the following applies:

I don't where would https://eel.is/c++draft/class.mem#general-31.sentence-1 enter, as neither the reinterpret_cast nor pointer-interconvertible require the addresses to be the same, as currently defined.

As for https://eel.is/c++draft/class.bit#3:

The address-of operator & shall not be applied to a bit-field, so there are no pointers to bit-fields.

This feels editorially weird, as ,so ... reads like a conclusion, not as normative wording. In my opinion that should be a note.

I think the issue is valid and bit-fields should be explicitly excluded from pointer-interconvertible.

I don't follow how you arrived at this conclusion. "pointer-interconvertible", as currently defined, doesn't depend on the address of the corresponding objects to be the same.

It's very simple – following the provisions of [basic.compound#6]:

If two objects are pointer-interconvertible, then they have the same address, and it is possible to obtain a pointer to one from a pointer to the other via a reinterpret_cast ([expr.reinterpret.cast]).

Perhaps you only paid attention to the situations in which objects are pointer-interconvertible, but did not pay attention to the definition of what effect this gives (as well as, in essence, the definition).

I don't where would https://eel.is/c++draft/class.mem#general-31.sentence-1 enter, as neither the reinterpret_cast nor pointer-interconvertible require the addresses to be the same, as currently defined.

As I stated above, I believe this clearly follows from the definition of "pointer-interconvertible" objects.

I think the issue is valid and bit-fields should be explicitly excluded from pointer-interconvertible.

I believe it is already explicitly excluded, since the [class.mem] clause explicitly states that in certain cases objects have the same address, which is accordingly required by the definition of pointer-interconvertible itself (which cannot be the case with bit-fields).

It seems to me that in this case, normative unity in the standard is ensured.

If two objects are pointer-interconvertible, then they have the same address, and it is possible to obtain a pointer to one from a pointer to the other via a reinterpret_cast ([expr.reinterpret.cast]).

This sentence always felt like a Note which is not formatted as one by accident

This sentence always felt like a Note which is not formatted as one by accident

But it's essentially a definition for "pointer-interconvertible-objects"

This sentence always felt like a Note which is not formatted as one by accident

But it's essentially a definition for "pointer-interconvertible-objects"

No, it is before this sentence.

Another issue with this wording is unnamed bit-fields:

struct{int:1,y;}y;

y and y.y should be pointer-interconvertible currently. Since the unnamed bit-field is not a member, the non-bit-field is the first non-static data member. Perhaps unnamed bit-fields with widths of zero should be exempt from this, since implementations do not change the class layout for initial unnamed bit-fields with widths of zero.

Maybe the fix can be...

Two non-bit-field objects a and b are pointer-interconvertible if
[...]
(6.3) - one is a standard-layout class object and the other is the first non-static data member of that object, where the member is not declared after any unnamed bit-field with positive width, or any base class subobject of that object ([class.mem]) or

This approach will make a bit-field object not even pointer-interconvertible with itself. But as there's no pointer to bit-field, the side effect might also be desired.

but in this case the criterion for "same address" is again not satisfied, since unnamed bit-fields contribute padding-bits.

CWG3209

CWG3209

For the change in [expr.unary.op]/3, [expr.unary.op]/5 already says:

The operand of & shall not be a bit-field.

It seems redundant to mention this twice.

Agreed; updated CWG3209.

Navigation Menu

Repository navigation

CWG3209 [basic.compound] Pointer-interconvertibility with bit-fields #916

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

CWG3209 [basic.compound] Pointer-interconvertibility with bit-fields #916

Description

Activity

jensmaurer commented on Jun 7, 2026

Halalaluyafail3 commented on Jun 7, 2026

jensmaurer commented on Jun 7, 2026

safocl commented on Jun 7, 2026

safocl commented on Jun 7, 2026

safocl commented on Jun 7, 2026

safocl commented on Jun 7, 2026

leni536 commented on Jun 7, 2026

safocl commented on Jun 7, 2026

safocl commented on Jun 7, 2026

languagelawyer commented on Jun 7, 2026

safocl commented on Jun 7, 2026

languagelawyer commented on Jun 7, 2026

Halalaluyafail3 commented on Jun 7, 2026

frederick-vs-ja commented on Jun 8, 2026

safocl commented on Jun 8, 2026

jensmaurer commented on Jun 29, 2026

Halalaluyafail3 commented on Jun 29, 2026

jensmaurer commented on Jun 30, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions