| Deutsch English Français Italiano |
|
<8634hn6ugo.fsf@linuxsc.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: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c
Subject: Re: So You Think You Can Const?
Date: Sun, 12 Jan 2025 23:31:19 -0800
Organization: A noiseless patient Spider
Lines: 34
Message-ID: <8634hn6ugo.fsf@linuxsc.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> <vlr8if$17rn$1@dont-email.me> <20250112130744.00000118@yahoo.com> <87cygsjmyr.fsf@nosuchdomain.example.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Mon, 13 Jan 2025 08:31:20 +0100 (CET)
Injection-Info: dont-email.me; posting-host="9eea8443f476a77794ac96904ee9ae64";
logging-data="1778439"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18T60O7QfrETlTMv6q55y7uERpHtRJgs7o="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:NFOkvaeFizUF7CDw9l1Cd/rBkIw=
sha1:LdUbLXyusCobMBbSSKsEmI3fmCQ=
Bytes: 2646
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.