Hi Serge, Martin,

On 2/24/23 02:21, Serge E. Hallyn wrote:
>> 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.
> 
> Again, p is just an n byte variable which happens to have (one hopes)
> pointed at a previously malloc'd address.
> 
> And I'd argue that pre-C11, this was not confusing, and would not have
> felt weird to you.
> 
> But I am most grateful to you for having brought this to my attention.
> I may not agree with it and not like it, but it's right there in the
> spec, so time for me to adjust :)

I'll try to show why this feels weird to me (even in C89):


alx@dell7760:~/tmp$ cat pointers.c
#include <stdio.h>
#include <stdlib.h>


int
main(void)
{
	char  *p, *q;

	p = malloc(42);
	if (p == NULL)
		exit(1);

	q = realloc(p, 42);
	if (q == NULL)
		exit(1);

	(void) &p;  // If we remove this, we get -Wuse-after-free

	printf("(%p == %p) = %i\n", p, q, (p == q));
}
alx@dell7760:~/tmp$ cc -Wall -Wextra pointers.c  -Wuse-after-free=3
alx@dell7760:~/tmp$ ./a.out
(0x5642cd9022a0 == 0x5642cd9022a0) = 1


This pointers point to different objects (actually, one of them doesn't 
even point to an object anymore), so they can't compare equal, according 
to both:

<http://port70.net/%7Ensz/c/c11/n1570.html#6.5.9p6>

<http://port70.net/~nsz/c/c89/c89-draft.html#3.3.9>

(I believe C89 already had the concept of lifetime well defined as it is 
now, so the object had finished it's lifetime after realloc(3)).

How can we justify that true, if the pointer don't point to the same 
object?  And how can we justify a hypothetical false (which compilers 
don't implement), if compilers will really just read the value?  To 
implement this as well defined behavior, it could result in no other 
than false, and it would require heavy overhead for the compilers to 
detect that the seemingly-equal values are indeed different, don't you 
think?  The easiest solution is for the standard to just declare this 
outlaw, IMO.

Maybe it could do an exception for printing, that is, reading a pointer 
is not a problem in itself, a long as you don't compare it, but I'm not 
such an expert about this.

Cheers,

Alex

> 
> -serge

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