| 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.