Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: So You Think You Can Const?
Date: Fri, 10 Jan 2025 10:37:46 -0800
Organization: None to speak of
Lines: 59
Message-ID: <87zfjyplad.fsf@nosuchdomain.example.com>
References: <vljvh3$27msl$1@dont-email.me> <vlma9m$2s5e5$1@dont-email.me>
	<vlo0cm$2dkpd$9@dont-email.me> <vlqd4j$3s4ai$1@dont-email.me>
	<874j27qfp7.fsf@nosuchdomain.example.com>
	<20250110122353.00005377@yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Fri, 10 Jan 2025 19:37:47 +0100 (CET)
Injection-Info: dont-email.me; posting-host="e16be66d43b38b7ea574a81744fe375a";
	logging-data="204683"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/o/3n/DwSO29fL6ty8UyIb"
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:wqLVZVhsnWiHuEHFFfDORse+Pvw=
	sha1:FOgeFUHZKjl525VU4Flts6tCmOY=
Bytes: 3443

Michael S <already5chosen@yahoo.com> writes:

> On Thu, 09 Jan 2025 23:40:52 -0800
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>
>> Andrey Tarasevich <andreytarasevich@hotmail.com> writes:
>> > On 01/09/25 12:12 AM, Julio Di Egidio wrote:  
>> >> I do not understand that: `free` is changing the pointed data, so
>> >> how can `const void *` even be "correct"?  
>> >
>> > `free` is destroying the pointed data.  
>> 
>> Right.  In other words, it causes the pointed-to data to reach the end
>> of its lifetime.  "Changing" the data generally means modifying its
>> value (that's what "const" forbids).
>> 
>> Given:
>> 
>>     int *ptr = malloc(sizeof *ptr);
>>     *ptr = 42;
>>     printf("*ptr = %d\n", *ptr);
>>     free(ptr);
>> 
>> After the call to free(), the int object logically no longer exists.
>> Also, the value of the pointer object ptr becomes indeterminate.
>> Attempting to refer to the value of either ptr or *ptr has undefined
>> behavior.
>
> I believe that the Standard really says that, but find the part about
> value of ptr variable ridiculous. It breaks natural hierarchy by which
> standard library is somewhat special, but it is not above rules of core
> language. free() is defined as function rather than macro. By rules of
> core language, a function call can not modify the value of local
> variable at caller's scope, unless pointers to the variable was passed
> to it explicitly.

Right, the call to free() doesn't change the value of ptr.

But that value, which is a valid pointer value before the call, becomes
indeterminate after the call.

You can even do something like this:

    int *ptr = malloc(sizeof *ptr); // assume malloc succeeded
    int *ptr1 = ptr + 1;
    free(ptr - 1);

In most or all actual implementations, referring to the value of ptr
after the free() for example with printf("%p", (void*)ptr), won't cause
any problems (unless the compiler peforms some optimization based on the
assumption that its value won't be accessed).  But one can imagine a
system that checks pointer values for validity every time they're
accessed; on such a system, reading the value of ptr might cause a trap.    

[...]

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */