Path: csiph.com!news.swapon.de!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c
Subject: Re: *rubeyes*: realloc(ptr, 0) is UB?
Date: Tue, 23 Jan 2024 22:15:04 -0800
Organization: A noiseless patient Spider
Lines: 52
Message-ID: <86mssvdzpz.fsf@linuxsc.com>
References: <20240116162506.143@kylheku.com> <pan$eed53$d5a25673$c4eed852$f5f44c0@invalid.invalid> <20240117160615.197@kylheku.com> <pan$b42aa$a1ca5f31$3fabcad$7e6ed64a@invalid.invalid> <20240118144637.733@kylheku.com> <pan$a4d49$9d845f9f$d4df4789$9fb1b256@invalid.invalid> <20240119083826.926@kylheku.com> <pan$bb552$50ca4b2e$1541d619$e7097d14@invalid.invalid> <uonlkk$15hqd$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: dont-email.me; posting-host="081b48eb4d739c8d0f1cd5168e73e868"; logging-data="1796010"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19DUJuNCLRtT+th+13eGpzFY7AiDh7eAWk="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:w1hqvKKORZMChsYmLfljpdL8sTM= sha1:OSmxq73uKX+notooeldbpjIsgjo=
Xref: csiph.com comp.lang.c:380756

James Kuyper <jameskuyper@alumni.caltech.edu> writes:

> On 1/22/24 18:12, Blue-Maned_Hawk wrote:
>
>> Kaz Kylheku wrote:
>>
>>> On 2024-01-19, Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> wrote:
>>>
>>>> Kaz Kylheku wrote:
>>>>
>>>>> Of course, that's not what "behavior can be readily inferred"
>>>>> means, no matter where I got the example.
>>>>
>>>> Inferences may be makeable, but they have no power.
>>>
>>> Yeah, tell that to your compiler when it surprisingly deletes
>>> code based on inference.
>>
>> Apologies, let me clarify:  In a technical standard, inferences
>> from nonnormative text cannot be used to make normative statements.
>
> True, but the relevant inferences were from normative text.  The
> context of the above comments has been snipped, so I'll repeat it
> here:
>
> On 1/17/24 19:10, Kaz Kylheku wrote:
>
>> On 2024-01-17, Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> wrote:
>>
>>> It looks to me like it was always undefined behavior, but it
>>> just wasn't explicitly stated as such in C99.
>>
>> That is incorrect.  A behavior for the following can be readily
>> inferred from C99:
>>
>>   void *p = malloc(42);
>
> Per C99:
> "The malloc function returns either a null pointer or a pointer to
> the allocated space."  (7.22.3.4p2)
>
> Thus, there are two possibilities:
> A: p == NULL
> B: p contains the address of a block of memory at least 42 bytes
> long, suitably aligned to store an object of any type.
>
> The standard does not mandate documentation of which of the two
> applies, so this has unspecified behavior.

The return value from malloc() is not unspecified behavior.  In
n1256, see section 7.20.3 paragraph 1, and also the definition of
unspecified behavior in 3.4.4.