Sujet : Re: So You Think You Can Const?
De : tr.17687 (at) *nospam* z991.linuxsc.com (Tim Rentsch)
Groupes : comp.lang.cDate : 13. Jan 2025, 08:31:19
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <8634hn6ugo.fsf@linuxsc.com>
References : 1 2 3 4 5 6 7 8 9
User-Agent : Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Keith Thompson <Keith.S.Thompson+
u@gmail.com> writes:
Michael S <already5chosen@yahoo.com> writes:
[...]
>
Tried to read the old discussion. Didn't understand much.
But it strengthened my opinion: it's ridiculous. Standard would be way
better with this nonsense removed.
The function below should be guaranteed by standard to return 42.
int foo(void)
{
char* a = malloc(100);
if (!a) return 42;
char* b = a + 42;
free(a);
return b - a;
}
>
How exactly would that be useful?
>
The intent, I think, is to allow for implementations that perform
checking when loading a pointer value. [...]
The motivation for the rule that pointers become indeterminate when
the object they point at has passed the end of its lifetime is that
the meaning of the bits in the pointer may have changed, and indeed
the pointer's bits might not even constitute a well-formed address.
Someone else posted a canonical example, where each stored pointer
holds a segment number and an offset within segment, and the
numbered segment no longer exists (which could happen on a free() or
even on a return from a function call, with each stack frame being
given its own segment). Loading a pointer into an "address
register" might want to precalculate an "absolute address", which of
course is not possible if the segment information no longer exists.