Deutsch   English   Français   Italiano  
<20250110104110.857@kylheku.com>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Kaz Kylheku <643-408-1753@kylheku.com>
Newsgroups: comp.lang.c
Subject: Re: So You Think You Can Const?
Date: Fri, 10 Jan 2025 19:11:05 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 72
Message-ID: <20250110104110.857@kylheku.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>
Injection-Date: Fri, 10 Jan 2025 20:11:06 +0100 (CET)
Injection-Info: dont-email.me; posting-host="04b5f0709b08f472ac875a8f159cacc9";
	logging-data="220805"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19Wf4U076f/7JuvAMZ2lgE9FSdvQ7yX/oY="
User-Agent: slrn/pre1.0.4-9 (Linux)
Cancel-Lock: sha1:fO8bHQ3s4EzB0dRVFi4TZ9FI6us=
Bytes: 3832

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

The library is above the rules because it is not required to be
written in strictly conforming ISO C.

The free function can communicate with the hardware (obviously in
a completely nonportable way that is outside of the C language) to put a
pointer value into a blacklist, such that any operation doing anything
with that pointer will trap.

Whether a value is valid or is a non-value* representation doesn't
necessarily depend in a static way on the value's bit pattern; the
machine could have a dynamically changing function which determines
whether a bit pattern is a value or non-value.

More practically speaking, suppose we have a situation like this:

   free(p);
   helper(p);

The helper(p) call can be diagnosed at translation time, because C
implementations can implement arbitrary diagnostics.

If p is an indeterminate value, then the call erroneous regardless of
what the function does with p, so that adds legitimacy to diagnosing it,
and even terminating translation.

In other words, a conforming ISO C implementation can reject a program
which, if it were not for the use of p, would otherwise be strictly
conforming in every other regard, and which stays within all
implementation limits.

---
*. Formerly "trap representations" in the C standard are now called
   non-value representations. Use of a non-value representation may
   generate a trap.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca