Sujet : Re: So You Think You Can Const?
De : Keith.S.Thompson+u (at) *nospam* gmail.com (Keith Thompson)
Groupes : comp.lang.cDate : 14. Jan 2025, 01:11:10
Autres entêtes
Organisation : None to speak of
Message-ID : <87ikqi9rvl.fsf@nosuchdomain.example.com>
References : 1 2 3 4 5 6 7
User-Agent : Gnus/5.13 (Gnus v5.13)
Tim Rentsch <
tr.17687@z991.linuxsc.com> writes:
[...]
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?
A quibble: it's the pointer *value* that becomes indeterminate,
not the pointer object. After free(p), p is still a valid pointer
object; you can take its address, store a new value in it, etc.
You just can't read its value without undefined behavior. Note also
that the argument to free() needn't be an lvalue; there might not
be an object holding the value that was passed to free().
As for free() not changing the bits in the pointer, I'm only
mostly sure that's guaranteed. On one hand, "An object exists,
has a constant address, and retains its last-stored value throughout
its lifetime.", which suggests that the bits don't change. On the
other hand, a program with defined behavior can't tell whether the
value changed, since it can't examine the pointer value. On the
other other hand, a program can tell whether the representation
changed by examining the pointer object as an array of unsigned char.
Can free(p) cause the representation of p to become what C23 calls
a "non-value representation", and what earlier editions called a
"trap representation"? If so, one could argue that p doesn't have a
"value", and perhaps the "last-stored value" wording doesn't apply.
I don't expect any implementation to do anything to the bits of
a pointer object whose value is passed to free(), but I'm wondering
whether an implementation that does so could be conforming.
-- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.comvoid Void(void) { Void(); } /* The recursive call of the void */