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
OpenPGP_signature
Description: OpenPGP digital signature
