Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: James Kuyper <jameskuyper@alumni.caltech.edu>
Newsgroups: comp.lang.c
Subject: Re: So You Think You Can Const?
Date: Fri, 10 Jan 2025 08:50:07 -0500
Organization: A noiseless patient Spider
Lines: 47
Message-ID: <vlr8if$17rn$1@dont-email.me>
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; charset=UTF-8
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 10 Jan 2025 14:50:08 +0100 (CET)
Injection-Info: dont-email.me; posting-host="4b4c26be421c251441cf4c792ca8c8fc";
	logging-data="40823"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19wt1C6TymN/KPH3HYNjlScx9K97ltsP4M="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:Oeet2MqKpGWo+MBVofZNfwVAW24=
Content-Language: en-US
In-Reply-To: <20250110122353.00005377@yahoo.com>

On 1/10/25 05:23, Michael S wrote:
> On Thu, 09 Jan 2025 23:40:52 -0800
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
....
>> 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.

And that applies to free() just as much as any user-defined function.

Keep in mind that if p is a value returned by a call to a memory
management function (alloc_aligned(), malloc(), calloc() or realloc()),
the values of all pointers anywhere in the program that point at any
location in the block of memory allocated by the call to that memory
management function become indeterminate at the same time. This doesn't
mean that free() has permission to change the bit pattern stored in any
of those pointer objects. It doesn't. There's no legal way to access the
values stored in those objects; the only thing you can do with those
objects as a whole is to store a new value in them. It is, however,
legal to access the individual bytes that make up the pointer's
representation. Those bytes are themselves objects, and changing the
values stored in those bytes would therefore violate 6.2.4p2: "An object
exists, has a constant address36) , and retains its last-stored value
throughout its lifetime."

What the indeterminate value of those pointers does mean is that
implementations have permission to remove that entire block of memory
from the list of valid pointer locations. On a system which uses memory
maps, that can be as simple as modifying one entry in the memory map table.

By the way, this argument was controversial when I made it in a
discussion on this newsgroup in 2003 in a thread titled "pointer after
free indeterminate (your example James)". Yes, I am the "James" in that
title. You can look up that thread using Google Groups, if you want to
examine the arguments for and against. I don't believe that there's been
any relevant changes in the standard, but it's been two decades and
several revisions of the standard, so I could be wrong about that.