Re: So You Think You Can Const?

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.

There is an important distinction here, one I suspect you are either
glossing over or missing.  The bits in the pointer don't change, but
the meaning of those bits can change.  To say that a different way,
what memory location a pointer object representation (the bits)
designates can depend on information outside the pointer object
itself, depending on the machine architecture.  A natural example is
a machine with segmented memory, where "a pointer" consists of a
segment number and an offset within the segment.  If a free() has
been done by marking a particular segment invalid (such as by
setting a bit in a global segment table), the bits in the pointer
passed to free() don't change, but those bits no longer refer to any
memory location.  The pointer becomes "indeterminate" even though
none of the bits in the pointer have changed.  Does that make sense?

Editorial sidebar:  in my opinion the C standard doesn't describe
what is going on here as well as it should.  What the C standard
says is that the (pointer) object becomes indeterminate.  What is
really happening is not that the object changes but that the stored
bits are no longer a valid value representation.  It would be more
accurate to say the validity of the object representation changes,
starting as valid before the free() and ending up as invalid after
the free().  Unfortunately there is some historical baggage tied to
the phrasing here, and so the description says the object becomes
indeterminate.