Path: csiph.com!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: *rubeyes*: realloc(ptr, 0) is UB?
Date: Mon, 22 Jan 2024 08:06:10 -0800
Organization: None to speak of
Lines: 28
Message-ID: <8734upbbf1.fsf@nosuchdomain.example.com>
References: <20240116162506.143@kylheku.com> <QdTpN.168167$vFZa.62153@fx13.iad> <20240117094759.508@kylheku.com> <9iYpN.354613$83n7.275953@fx18.iad> <86r0ifjbiw.fsf@linuxsc.com> <QfbqN.230722$c3Ea.54531@fx10.iad> <uobqhg$2mt8c$1@dont-email.me> <20240118112920.465@kylheku.com> <uoc030$2ndid$2@dont-email.me> <20240118144021.3@kylheku.com> <87r0iech8j.fsf@nosuchdomain.example.com> <87msszbb08.fsf@nosuchdomain.example.com> <86cytugvve.fsf@linuxsc.com> <87edeab85u.fsf@nosuchdomain.example.com> <wwvv87lwzuo.fsf@LkoBDZeT.terraraq.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Info: dont-email.me; posting-host="9cd31264156fc70cf12828e27041ba36"; logging-data="845347"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19O8/OziSqj4YuBqWDvE7E5"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
Cancel-Lock: sha1:J15maQjYhcqhn51C/tcY8S3O9oc= sha1:/w6pV1xlcsIeWzNmw0oq6gfo6Rk=
Xref: csiph.com comp.lang.c:380624

Richard Kettlewell <invalid@invalid.invalid> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>> It's trivial to fix that problem:  simply require implementations
>>> to define a preprocessor symbol about how the implementation
>>> works.  Problem solved.
>>>
>>> (There are other instances of implementation-defined behavior
>>> that would benefit from analogous changes along these lines.)
>>
>> I tend to agree that such a preprocessor symbol would be an improvement.
>>
>> I still think, as I wrote above, that removing the permission to
>> return a null pointer on a successful zero-sized allocation would be a
>> greater improvement.
>
> Fully agreed. That permission has been grit in the gears for a very long
> time, for much of which I had the misfortune of having to deal with it
> in real life thanks to IBM’s bad decisions.

Can you expand on "IBM's bad decisions"?

[...]

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */