Missed warning (-Wuse-after-free)

Alex Colomar alx.manpages@gmail.com
Fri Feb 24 00:02:54 GMT 2023

Hi Martin,

On 2/23/23 20:57, Martin Uecker wrote:
> Am Donnerstag, dem 23.02.2023 um 20:23 +0100 schrieb Alex Colomar:
>> Hi Martin,
>> On 2/17/23 14:48, Martin Uecker wrote:
>>>> This new wording doesn't even allow one to use memcmp(3);
>>>> just reading the pointer value, however you do it, is UB.
>>> memcmp would not use the pointer value but work
>>> on the representation bytes and is still allowed.
>> Hmm, interesting.  It's rather unspecified behavior. Still
>> unpredictable: (memcmp(&p, &p, sizeof(p) == 0) might evaluate to true or
>> false randomly; the compiler may compile out the call to memcmp(3),
>> since it knows it won't produce any observable behavior.
>> <https://software.codidact.com/posts/287905>
> No, I think several things get mixed up here.
> The representation of a pointer that becomes invalid
> does not change.
> So (0 === memcmp(&p, &p, sizeof(p)) always
> evaluates to true.
> Also in general, an unspecified value is simply unspecified
> but does not change anymore.
> Reading an uninitialized value of automatic storage whose
> address was not taken is undefined behavior, so everything
> is possible afterwards.
> An uninitialized variable whose address was taken has a
> representation which can represent an unspecified value
> or a no-value (trap) representation. Reading the
> representation itself is always ok and gives consistent
> results. Reading the variable can be undefined behavior
> iff it is a trap representation, otherwise you get
> the unspecified value which is stored there.
> At least this is my reading of the C standard. Compilers
> are not full conformant.

Does all this imply that the following is well defined behavior (and 
shall print what one would expect)?


   (void) &p;  // take the address
   // or maybe we should (void) memcmp(&p, &p, sizeof(p)); ?

   printf("%p\n", p);  // we took previously its address,
                       // so now it has to hold consistently
                       // the previous value

This feels weird.  And a bit of a Schroedinger's pointer.  I'm not 
entirely convinced, but might be.



> Martin

GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20230224/cde71885/attachment-0001.sig>

More information about the Gcc mailing list