P2434 [basic.types.general] [basic.compound] Pointer values are not determined by bits in the object representation

[languagelawyer]

Full name of submitter: Andrey Erokhin

Reference (section label): [basic.types.general] [basic.compound]

Link to reflector thread (if any): -

Issue description:

(Wanted to file the issue for many years)

[basic.types.general] says:

For trivially copyable types, the value representation is a set of bits in the object representation that determines [emphasis mine] a value, which is one discrete element of an implementation-defined set of values.

For pointers, bits in their representation can't determine the value.

A simple example:

int a[2][2];

int* p1 = &a[0][2];
int* p2 = &a[1][0];

p1 and p2 usually have the same bits in their representation, but they are different values.

And, ofc, one can produce arbitrary number of pointer values with the same representation, but different values by replacing an object:

int i;

int* p1 = &i;
std::byte buf[sizeof(p1)];
std::memcpy(buf, &p1, sizeof(p1)); // save the value

int* p2 = ::new(&i) int; // rebinds p1 (is it a write to p1?)
std::memcpy(&p1, buf, sizeof(p1)); // restore p1 value

p1 and p2 point to different objects (thus have different values), but bits in their representation are usually the same

Suggested resolution:

Exclude pointers from trivially copyable types

[safocl]

p1 and p2 usually have the same bits in their representation, but they are different values.

But they point to different places — p1 points to the byte following the last byte of the object representation of the second array element (pointer past the end of an object) — that is, beyond the last array element. Such a pointer cannot be guaranteed to point to the first array element at index 1 from the first nesting. Pointer p2 points to the first array element at index 1 from the first nesting.
(This is also the reason why it is impossible to apply std::launder to a pointer to the second nesting of an array.)

[languagelawyer]

@safocl what's the point of your comment? You seem agree/confirm that they are different values, but you start with «But»

[safocl]

p1 and p2 point to different objects (thus have different values), but bits in their representation are usually the same

[basic.types.general#3] guarantees that if you copy an object representation, it will have the same value. But you don't see this happening in the example provided. So, I think the examples are irrelevant for discussing the standard's shortcomings. But perhaps they are relevant for the EWG language change proposal.

[languagelawyer]

@safocl https://eel.is/c++draft/basic.types.general#2?

[safocl]

@safocl https://eel.is/c++draft/basic.types.general#2?

p3

[t3nsor]

this issue is already fixed by P2434

[languagelawyer]

@safocl https://eel.is/c++draft/basic.types.general#2?

p3

Irrelevant, I'm using p2

[safocl]

@safocl what's the point of your comment? You seem agree/confirm that they are different values, but you start with «But»

In your example, there is no non-determinism involved - your pointers simply point to different memory locations.

[languagelawyer]

@safocl what's the point of your comment? You seem agree/confirm that they are different values, but you start with «But»

In your example, there is no non-determinism involved - your pointers simply point to different memory locations.

Why non-determinism have to be involved?

[safocl]

p1 and p2 point to different objects (thus have different values), but bits in their representation are usually the same

Irrelevant, I'm using p2

What I'm saying is that the rule in p3 guarantees what you'd like to see, but you don't use it — you simply create a new pointer without copying the object representation from pointer p1 into it. Therefore, there's no guarantee of the same value.

[languagelawyer]

p1 and p2 point to different objects (thus have different values), but bits in their representation are usually the same

Irrelevant, I'm using p2

What I'm saying is that the rule in p3 guarantees what you'd like to see

I think you miss what I'd like to see. I want to restore p1 original value

[t3nsor]

this issue is already fixed by P2434

... and we adopted this paper in Brno, so I don't believe there is anything left for this issue.