Deutsch   English   Français   Italiano  
<867c6z6vfg.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:10:27 -0800
Organization: A noiseless patient Spider
Lines: 50
Message-ID: <867c6z6vfg.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> <vm0s3p$17mss$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Mon, 13 Jan 2025 08:10:28 +0100 (CET)
Injection-Info: dont-email.me; posting-host="9eea8443f476a77794ac96904ee9ae64";
	logging-data="1778439"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18Hbux5x3kD6D8gblVJtSj4bHlU7GB1t7Y="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:0ZHnFk0g/oqpiRqPtYQRy7ltGrU=
	sha1:muNK/OLho10YQTBFhuhndzn9ncE=
Bytes: 2994

Richard Harnden <richard.nospam@gmail.invalid> writes:

> On 12/01/2025 11:22, Keith Thompson wrote:
>
>> 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.  It's possible that there
>> currently are no such implementations, but even so, how would
>> reading a free()d pointer value be useful?
>>
>> I'd say that passing a pointer value to free() means you no longer care
>> about it.
>
> What if, after the free(a), you have ...
>
> char *b = malloc(100);
>
> ... and the old address of 'a' gets reused.
>
> Could you then carry on using 'a'?
>
> You'd be relying on chance, and it'd be terribly bad form ... but
> would it be legal?

The short answer is it would be a mistake to keep using a.

The reason for this is as follows.  Even if the bits of a and
the bits of b are the same, and even if the two sets of bits
mean the same thing as far as the hardware is concerned, they
don't have to mean the same thing as far as a C compiler is
concerned.  The C standard empowers C implementations to treat
any further accesses to a in any way they choose, even when as
far the hardware is concerned a and b are interchangeable.