Deutsch   English   Français   Italiano  
<86tta37e6k.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 16:25:23 -0800
Organization: A noiseless patient Spider
Lines: 34
Message-ID: <86tta37e6k.fsf@linuxsc.com>
References: <vljvh3$27msl$1@dont-email.me> <vlma9m$2s5e5$1@dont-email.me> <vlolsf$3cnll$4@dont-email.me> <vlqd9p$3s4ai$2@dont-email.me> <vlqstb$3uk5j$1@dont-email.me> <87v7umpkfv.fsf@nosuchdomain.example.com> <vltjqc$j8n0$1@dont-email.me> <vlu508$ht1i$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Mon, 13 Jan 2025 01:25:27 +0100 (CET)
Injection-Info: dont-email.me; posting-host="9eea8443f476a77794ac96904ee9ae64";
	logging-data="1562055"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/vc/B8y1F7r53oDKtdAM9wWWZou30AQxs="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:Pjv7seLmLOUGMSb10y8/n1xvLxo=
	sha1:DDGRaAb9CyQUjNtyYf2I6gfaR94=
Bytes: 2601

Julio Di Egidio <julio@diegidio.name> writes:

> On 11/01/2025 12:14, David Brown wrote:
>
>> On 10/01/2025 19:56, Keith Thompson wrote:
>
> <snip>
>
>> The idea was to place the emphasis on "free" changing the pointer,
>> rather than the data pointed to.
>
> I feel I am still altogether missing the point.
>
> Is my understanding correct that when freeing a pointer: 1) the
> pointer value, i.e. the address it holds, does not change;  OTOH, 2)
> the pointed-to object does change, in the sense that it is marked
> unusable (and, supposedly, made available to re-allocation)?

Not exactly.  The bits in the pointer don't change.  The _meaning_
of those bits, which is to say what address the bits correspond to,
or even if there is a corresponding address, _does_ change, in the
sense that any attempt (in a C program) to look at the bits as an
address is -- as far as the C standard is concerned -- completely
unpredictable.

> Moreover, while the pointer value has not changed, it is in fact
> changed in the sense that it has become invalid, namely the pointer
> cannot be used (validly dereferenced) anymore.  Not just that, but
> *every* pointer to the same object, i.e. holding the same address, has
> become invalid.

It isn't just that those pointers cannot be dereferenced.  Even
trying to load their values might blow up the program, or even do
anything else one might imagine.