Re: Missed warning (-Wuse-after-free)

[Alex Colomar <alx.manpages@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2380 bytes --]

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)?

   free(p);

   (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.

Cheers,

Alex

> 
> 
> Martin
> 
> 
> 
> 
> 
> 
> 

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]