Hi Martin,

On 2/17/23 09:12, Martin Uecker wrote:
> Am Freitag, dem 17.02.2023 um 02:04 +0100 schrieb Alejandro Colomar
> 
> 
>>
>> [...]
>>
>>>
>>> I'm not convinced that it's useful to the end-user to warn about
>>> the
>>> "use of q itself" case.
>>
>> I didn't quote the standard because I couldn't find it.  I was
>> searching in C11,
>> and it seems that it was only implicitly Undefined Behavior, without
>> explicit
>> spelling (the value of the pointer was indeterminate, according to
>> C11).
> 
> The value becomes indeterminate according to 6.2.4p2 in C11.
> An indeterminate value may be a trap representation 3.19.2
> If such a trap representation is read (the pointer, not
> just the pointed-to object), the behavior is undefined
> according to 6.2.6.1p5. So it is explitely UB and was
> already in C99 or even before.

What if the comparison is performed as uintptr_t?
You wouldn't have trap representations, would you?
Or we could even go to memcmp(3) to compare as char,
if paranoic enough :)

> 
> 
>> Now C23 will better clarify that reading such a pointer value (not
>> ever dereferencing) is Undefined Behavior.
> 
> We did not change this for C23.

C11:

The value of a pointer becomes indeterminate when
the object it points to (or just past)
reaches the end of its lifetime.
<https://port70.net/%7Ensz/c/c11/n1570.html#6.2.4p2>

C2x (N3054 is the latest I know):

If a pointer value is used in an evaluation after
the object the pointer points to (or just past)
reaches the end of its lifetime,
the behavior is undefined.
<https://www.open-std.org/JTC1/SC22/WG14/www/docs/n3054.pdf#subsection.6.2.4>


This new wording doesn't even allow one to use memcmp(3);
just reading the pointer value, however you do it, is UB.


> 
> Only the terminology regarding trap representation
> (now: non-value representation) and indeterminate
> values (now: indeterminate representation) was revised.
> 
> 
> There are proposal to define bevahior for such
> pointers, but I think this would be a mistake.
> (although somehow I ended up being a co-author 
> of this paper),
> 
> The reason is that every use of such a pointer 
> risks running into sublte issues related to pointer 
> provenance.
> 
> So in my opinion it would be very useful to warn about
> all uses of invalid pointers, because fixing this is
> much easier than understanding and fixing provenance
> issues which might arise from incorrect use of such
> pointers.

Agree; making this defined behavior doesn't seem a good idea.

Cheers,

Alex

> 
> 
> Martin

-- 
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5