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 20:58:55 -0500
Organization: A noiseless patient Spider
Lines: 32
Message-ID: <vlsj90$ahq3$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>
 <20250110104110.857@kylheku.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 11 Jan 2025 02:58:56 +0100 (CET)
Injection-Info: dont-email.me; posting-host="b612924d5bfdf050c235cb51d03338be";
	logging-data="345923"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18EQWMoY8ATXJMR/UdeAxnv4/obKloGEO4="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:qltyDywszTkHE7kqxW4MUlbbA6s=
Content-Language: en-US
In-Reply-To: <20250110104110.857@kylheku.com>

On 1/10/25 14:11, Kaz Kylheku wrote:
> On 2025-01-10, Michael S <already5chosen@yahoo.com> wrote:
>> On Thu, 09 Jan 2025 23:40:52 -0800
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
....
>>>     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.
> 
> The library is above the rules because it is not required to be
> written in strictly conforming ISO C.

True, but not as relevant as you think. The key point is that
interactions between the library and with user-written C code needs to
behave according to the rules of C, whether or not the function is
written in C. In particular, since free() is defined as receiving a
pointer value, rather than a pointer to that pointer, it should have no
way of changing the original pointer. You've described how it can render
that pointer's value invalid, without any change to the pointer itself.
And that is true whether or not malloc() is written in strictly conforming C