Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

[context]

>>>> "Catch-23: The New C Standard,Sets the World on Fire"
>>>> by Terence Kelly
>>>> https://queue.acm.org/detail.cfm?id=3588242

[...]

> But their example stack code lends itself to a puzzle: on what
> implementation assumptions does it depend? I believe it is not
> fully portable for reasons that are unrelated to the realloc
> implementation. [...]

Can you elaborate on this comment? I don't see what you're
getting at.

In article <u0jvkb$20c26$1@news.xmission.com>,
Kenny McCormack <gazelle@shell.xmission.com> wrote:
>In article <u0jrr7$jvd$2@reader2.panix.com>,
>Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>...
>>To be explicit about it: realloc(ptr, 0); is not, and never has
>>been, guaranteed to be equivalent to free(ptr).
>
>It is, on platforms where it is. A tautology, that.

Or in C89 (I was wrong on that).

>Beyond that, I have no further interest in this, as we'd just be arguing
>about angels and pins.

How portable are these pins?
(I kid! I kid!)

- Dan C.

David Brown <david.brown@hesbynett.no> writes:
> On 05/04/2023 15:29, Dan Cross wrote:
>> In article <874jpv84uv.fsf@bsb.me.uk>,
>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>
>>> I got the impression they knew that. However, in C89, realloc(ptr, 0)
>>> must behave like free(ptr). That changed, I think, in C99 with the
>>> removal of that guarantee. There is some evidence that they are little
>>> confused about that guarantee having been lost, thought of course it is
>>> still permitted.
>> Indeed, you are correct. From C89, 7.10.3.3: "if *size* is zero
>> and *ptr* is not a null pointer, the object it points to is
>> freed."
>
> I don't have a C89 reference handy, but I don't think realloc(ptr, 0)
> has ever been required to behave like free(ptr). That is one of the
> allowed behaviours, but it is not the only one. In particular, even
> if it first acts like free(ptr), it can then allocate a zero-size
> buffer afterwards. Thus it may not be behaving like free(ptr) alone -
> it can do more. And if you don't take that into account, your code
> will leak memory.

ISO C90:

7.10.3 Memory management functions

[...]
If the space cannot be allocated, a null pointer is returned. If
the size of the space requested is zero, the behavior is
implementation-defined; the value returned shall be either a
null pointer or a unique pointer.

...

7.10.3.4 The realloc function

Synopsis

#include <stdlib.h>
void *realloc(void *ptr, size_t size);

Description

The `realloc` function changes the size of the object pointed
to by `ptr` to the size specified by `size`. The contents of
the object shall be unchanged up to the lesser of the new and
old sizes. If the new size is larger, the value of the newly allocated portion of the object is indeterminate. If `ptr` is a
null pointer, the `realloc` function behaves like the `malloc`
function for the specified size. Otherwise, if `ptr` does not
match a pointer earlier returned by the `calloc`, `malloc`, or
`realloc` function, or if the space has been deallocated by a call
to the `free` or `realloc` function. the behavior is undefined.
If the space cannot be allocated, the object pointed to by `ptr`
is unchanged. If `size` is zero and `ptr` is not a null pointer,
the object it points to is freed.

Returns

The `realloc` function returns either a null pointer or a pointer
to the possibly moved allocated space.

ISO C99 expands the "Memory management functions" description:

If the size of the space requested is zero, the behavior is
implementation- defined: either a null pointer is returned, or the
behavior is as if the size were some nonzero value, except that the
returned pointer shall not be used to access an object.

Where C90 says that realloc changes the size of the object, C99 says
that it deallocates the old object and allocates a new one. This isn't
a change in behavior, but it more accurately describes what's going on.

If `ptr` is a null pointer, the `realloc function behaves like the
`malloc` function for the specified size. Otherwise, if `ptr` does
not match a pointer earlier returned by the `calloc`, `malloc`, or
`realloc` function, or if the space has been deallocated by a call
to the `free` or `realloc` function, the behavior is undefined. If
memory for the new object cannot be allocated, the old object is not
deallocated and its value is unchanged.

Returns

The `realloc` function returns a pointer to the new object (which
may have the same value as a pointer to the old object), or a null
pointer if the new object could not be allocated.

C11 makes a few minor changes (adding references to aligned_alloc and
"fundamental alignment requirement").

C17 makes a few minor changes, but nothing relevant to the current
discussion.

C23 (N3096 draft) makes some more changes:

Any bytes in the new object beyond the size of the old object have
[indeterminate->unspecified] values.

Otherwise, if ptr does not match a pointer earlier returned by a
memory management function, or if the space has been deallocated by
a call to the free or realloc function, [+or if the size is zero+],
the behavior is undefined.

References:

C99 draft: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf
C11 draft: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
C23 draft: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3096.pdf

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

In article <u0k3au$3uelq$1@dont-email.me>,
David Brown <david.brown@hesbynett.no> wrote:
>On 05/04/2023 15:29, Dan Cross wrote:
>> In article <874jpv84uv.fsf@bsb.me.uk>,
>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>
>>> I got the impression they knew that. However, in C89, realloc(ptr, 0)
>>> must behave like free(ptr). That changed, I think, in C99 with the
>>> removal of that guarantee. There is some evidence that they are little
>>> confused about that guarantee having been lost, thought of course it is
>>> still permitted.
>>
>> Indeed, you are correct. From C89, 7.10.3.3: "if *size* is zero
>> and *ptr* is not a null pointer, the object it points to is
>> freed."
>
>I don't have a C89 reference handy, but I don't think realloc(ptr, 0)
>has ever been required to behave like free(ptr). That is one of the
>allowed behaviours, but it is not the only one. In particular, even if
>it first acts like free(ptr), it can then allocate a zero-size buffer
>afterwards. Thus it may not be behaving like free(ptr) alone - it can
>do more. And if you don't take that into account, your code will leak
>memory.

What I quoted above is the actual text from C89. To repeat:

"If *size* is zero and *ptr* is not a null pointer,
the object it points to is freed."

(C89, sec 7.10.3.3.)

- Dan C.

cross@spitfire.i.gajendra.net (Dan Cross) writes:

> In article <u0jem9$2033d$1@news.xmission.com>,
> Kenny McCormack <gazelle@shell.xmission.com> wrote:
>>In article <u0jcmt$3r2ce$1@dont-email.me>, Rene Kita <mail@rkta.de> wrote:
>>>Kenny McCormack <gazelle@shell.xmission.com> wrote:
>>>> In article <u0gs80$3cmm0$1@dont-email.me>, Rene Kita <mail@rkta.de> wrote:
>>>>>Lynn McGuire <lynnmcguire5@gmail.com> wrote:
>>>>>> "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly
>>>>>> with Special Guest Borer Yekai Pan
>>>>>> https://queue.acm.org/detail.cfm?id=3588242
>>>>>
>>>>>That was an interesting read. I stick to C99 I'll guess.
>>>>
>>>> Just out of curiosity, what *is* the big breaking change?
>>>
>>>realloc with a size of zero is UB in C23.
>>
>>Interesting.
>>
>>I had no idea that realloc with a size of zero is (was?) equivalent to a
>>call to free() - until I read the man page a day or so ago and found that.
>>
>>So, no more...?
>
> The thing is, that is, and always has been, implementation
> defined.

No, I don't think so. The /return value/ is, and always has been,
implementation defined, but, in ANSI C (1989), realloc(ptr, 0) was
defined to free the pointer. That changed in C99 (I think), though it
was simply left unstated what would happen, so an implementation is not
even obliged to document if it frees the pointer or not.

> The authors presented it as a universal property of
> all implementations, but it just is not.

I don't think they do. They state that "The C89 and C99 standards
committees strongly recommended that allocation interfaces malloc,
calloc, and realloc return a null pointer in response to zero-byte
requests" and that this "implies that realloc(p,0) should
unconditionally free(p)". I don't know where that recommendation comes
from (the PDF is missing footnotes > 27) and the implication seems to be
a bit of a stretch, but if they just assumed this to be universal, why
explain that it was recommended?

> To be explicit about it: realloc(ptr, 0); is not, and never has
> been, guaranteed to be equivalent to free(ptr).

Have you checked ANSI C? I think it was guaranteed in those days,
though I don't have an official copy.

--
Ben.

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
> [context]
>
>>>>> "Catch-23: The New C Standard,Sets the World on Fire"
>>>>> by Terence Kelly
>>>>> https://queue.acm.org/detail.cfm?id=3588242
>
> [...]
>
>> But their example stack code lends itself to a puzzle: on what
>> implementation assumptions does it depend? I believe it is not
>> fully portable for reasons that are unrelated to the realloc
>> implementation. [...]
>
> Can you elaborate on this comment? I don't see what you're
> getting at.

What happens when sizeof int == 1?

--
Ben.

Le 05/04/2023 à 13:54, Richard Damon a écrit :
> On 4/4/23 11:10 PM, Opus wrote:
>> Le 05/04/2023 à 04:36, Ben Bacarisse a écrit :
>>> I don't think the code was ever perfectly reasonable, but I took their
>>> point to be simply that it was not undefined as it will become.
>>
>> Yeah, to be fair, in standard versions before C17, this was a bit of a
>> grey area. While the behavior of realloc (like malloc and calloc)
>> *regarding the new allocation* was clearly implementation-defined, the
>> behavior as to the old object passed as parameter was, at best, implicit.
>>
>> "The realloc function  deallocates  the  old  object  pointed  to  by
>> ptr and  returns  a pointer  to  a  new object  that  has  the  size
>> specified  by size."
>>
>> The implicit part is that we could assume from the above that whatever
>> the size parameter is, the realloc function starts by deallocating the
>> old object, and what happens after that is implementation-defined if
>> size is 0.
>>
>> C17 makes it more explicit and definitely makes it clear that even the
>> deallocation is implementation-defined in this case. So this was at
>> least known for sure with C17 that the deallocation itself was
>> implementation-defined. Nothing new.
>>
>> But the old phrasing was so unexplicit that it was reasonable not to
>> count on any particular behavior.
>>
>> Reading the article and the point about the cost of the standard, it's
>> not completely clear the author(s) had really read the previous
>> versions very attentively anyway.
>>
>> What it really shows IMO and is backed up by experience is that many,
>> if not most C developers have never read the C std anyway and many
>> assume they know C from their own experience and the behavior of the
>> particular   tools they have used.
>>
>> Whether this would change if the standard became a free download
>> remains to be seen. I am skeptical. Drafts are not hard to get ahold
>> of and late drafts are usually close enough to the final text.
>>
>
> The issue is that realloc DOESN'T start by deallocating the old buffer,
> but must allocate the new buffer (possibly just resizing the existing
> buffer in place), and then copying the data if needed.

All the standard says is what I quoted above. It absolutely doesn't
state that it must allocate the new buffer *before* deallocating, even
if it appears to make complete sense from a functional POV - since
realloc has to copy existing data. So, functionally speaking, I agree
that the implementation couldn't do anything else, but in a standard,
you have to be extra explicit, and in this case, it wouldn't have been
hard to do so.

The description STARTS with "The realloc function deallocates the old
object pointed to by ptr".

It is definitely pretty badly written, at best.
A simple algorithm in pseudo-code instead of this relatively confusing
sequence of sentences would have done the trick.

But as I said, it was described so badly that between this and what you
pointed out, it has always been reasonable not to count on any
reasonable behavior when passing 0 as size. I have personally never done
that, but I certainly have seen it in third-party code, and again it all
comes more from relying on the behavior of particular implementations
that from a confusing phrasing in the std, which most have not read anyway.

cross@spitfire.i.gajendra.net (Dan Cross) writes:

> In article <874jpv84uv.fsf@bsb.me.uk>,
> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>>>>[snip]
>>>>I agree with the authors that the change declaring realloc(..., 0) to be
>>>>undefined is worrying, but I can't follow their reasoning about the
>>>>history. They suggest something had already happened in C17 that set C
>>>>on a course towards this "breaking change" but I can't find what they
>>>>refer to.
>>>
>>> The authors, bluntly, wrong: the behavior of realloc() when the
>>> size argument is 0, the implementation is, as it always has
>>> been since C89, implementation defined.
>>
>>I got the impression they knew that.

>> in C89, realloc(ptr, 0) must behave like free(ptr)

> Indeed, you are correct. From C89, 7.10.3.3: "if *size* is zero
> and *ptr* is not a null pointer, the object it points to is
> freed."

Sorry, I must be reading the thread in the wrong order as I replied to
something less before seeing this. This thread has become very noisy
and really did not need my repeating information!

--
Ben.

cross@spitfire.i.gajendra.net (Dan Cross) writes:

> In article <87zg7n89zw.fsf@bsb.me.uk>,
> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:

[context]

>>>>> "Catch-23: The New C Standard,Sets the World on Fire"
>>>>> by Terence Kelly
>>>>> https://queue.acm.org/detail.cfm?id=3588242

[...]

>> But their example stack code lends itself to a puzzle: on
>> what implementation assumptions does it depend? I believe it
>> is not fully portable for reasons that are unrelated to the
>> realloc implementation. [...]

> The authors, bluntly, wrong: the behavior of realloc() when
> the size argument is 0, the implementation is, as it always has
> been since C89, implementation defined.

As noted downthread, that statement isn't right in the particular
case of C89/C90.

> [...] The authors tried to make it out like their code was
> portable and well-defined. [...]

I have to disagree here. The example code is discussed under
the aegis of what the authors term a "zero-null" allocator
implementation, where (among other things) 'realloc(p,0)' always
does a 'free(p)', and will always return NULL. They aren't
making any claims for any other implementations.

In article <87bkk26sx1.fsf@bsb.me.uk>,
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>[snip]
>> To be explicit about it: realloc(ptr, 0); is not, and never has
>> been, guaranteed to be equivalent to free(ptr).
>
>Have you checked ANSI C? I think it was guaranteed in those days,
>though I don't have an official copy.

I did, and indeed I was mistaken vis C89. See my other
responses in this thread where I quote the standard.

C99 and later explicitly say that the old value is deallocated
and the new value allocated. However, one cannot detect the
difference between an error condition and an implementation that
returns NULL in response to a zero-sized allocation from the
return value alone.

I stand by my critique of the authors' code.

- Dan C.

On 05/04/2023 20:55, Dan Cross wrote:
> In article <u0k3au$3uelq$1@dont-email.me>,
> David Brown <david.brown@hesbynett.no> wrote:
>> On 05/04/2023 15:29, Dan Cross wrote:
>>> In article <874jpv84uv.fsf@bsb.me.uk>,
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>
>>>> I got the impression they knew that. However, in C89, realloc(ptr, 0)
>>>> must behave like free(ptr). That changed, I think, in C99 with the
>>>> removal of that guarantee. There is some evidence that they are little
>>>> confused about that guarantee having been lost, thought of course it is
>>>> still permitted.
>>>
>>> Indeed, you are correct. From C89, 7.10.3.3: "if *size* is zero
>>> and *ptr* is not a null pointer, the object it points to is
>>> freed."
>>
>> I don't have a C89 reference handy, but I don't think realloc(ptr, 0)
>> has ever been required to behave like free(ptr). That is one of the
>> allowed behaviours, but it is not the only one. In particular, even if
>> it first acts like free(ptr), it can then allocate a zero-size buffer
>> afterwards. Thus it may not be behaving like free(ptr) alone - it can
>> do more. And if you don't take that into account, your code will leak
>> memory.
>
> What I quoted above is the actual text from C89. To repeat:
>
> "If *size* is zero and *ptr* is not a null pointer,
> the object it points to is freed."
>
> (C89, sec 7.10.3.3.)
>
> - Dan C.
>

I am not disagreeing with that. My point is what happens /after/ the
pointer ptr is freed. As far as I can tell (and I could be wrong), the
function can behave in a manner similar to malloc(0) - it can either do
no allocation and return a null pointer (in which case the whole thing
is like free(ptr)), or it could allocate a zero-size object and return a
unique pointer. (Or it could try to do such an allocation, and fail,
possibly affecting errno.) It is this aspect that is, as far as I can
tell, implementation dependent and non-portable.

David Brown <david.brown@hesbynett.no> writes:
> On 05/04/2023 20:55, Dan Cross wrote:
>> In article <u0k3au$3uelq$1@dont-email.me>,
>> David Brown <david.brown@hesbynett.no> wrote:
>>> On 05/04/2023 15:29, Dan Cross wrote:
>>>> In article <874jpv84uv.fsf@bsb.me.uk>,
>>>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>>
>>>>> I got the impression they knew that. However, in C89, realloc(ptr, 0)
>>>>> must behave like free(ptr). That changed, I think, in C99 with the
>>>>> removal of that guarantee. There is some evidence that they are little
>>>>> confused about that guarantee having been lost, thought of course it is
>>>>> still permitted.
>>>>
>>>> Indeed, you are correct. From C89, 7.10.3.3: "if *size* is zero
>>>> and *ptr* is not a null pointer, the object it points to is
>>>> freed."
>>>
>>> I don't have a C89 reference handy, but I don't think realloc(ptr, 0)
>>> has ever been required to behave like free(ptr). That is one of the
>>> allowed behaviours, but it is not the only one. In particular, even if
>>> it first acts like free(ptr), it can then allocate a zero-size buffer
>>> afterwards. Thus it may not be behaving like free(ptr) alone - it can
>>> do more. And if you don't take that into account, your code will leak
>>> memory.
>> What I quoted above is the actual text from C89. To repeat:
>> "If *size* is zero and *ptr* is not a null pointer,
>> the object it points to is freed."
>> (C89, sec 7.10.3.3.)
>> - Dan C.
>>
>
> I am not disagreeing with that. My point is what happens /after/ the
> pointer ptr is freed. As far as I can tell (and I could be wrong),
> the function can behave in a manner similar to malloc(0) - it can
> either do no allocation and return a null pointer (in which case the
> whole thing is like free(ptr)), or it could allocate a zero-size
> object and return a unique pointer. (Or it could try to do such an
> allocation, and fail, possibly affecting errno.) It is this aspect
> that is, as far as I can tell, implementation dependent and
> non-portable.

If realloc(ptr, 0) returns a null pointer, then its behavior is subtly
different from that of free(), which doesn't return a value. That's a
minor quibble.

The standard doesn't say that any of the memory allocation functions set
errno, so any of them could set it to any non-zero value regardless of
whether they succeed or fail.

Under C89/C90 rules, realloc(ptr, 0) definitely frees the object pointed
to by ptr (assuming it had been allocated properly). The standard
doesn't clearly say what realloc() returns in that case. Common sense
suggests that it behaves like malloc(0), so it returns either a null
pointer or a unique pointer (and the choice is implementation-defined,
so it must be documented). The caller can easily tell whether it
returned a null pointer or not, and in either case it can safely pass
the result to free().

ptr1 = malloc(42);
ptr2 = realloc(ptr1, 0);
// At this point, we know that the 42-byte object has been freed
free(ptr2); // this is safe and avoids any memory leak

In C99 and later, the description of realloc() doesn't specifically
address the case of size==0. But since it says that it deallocates
the old object and allocates a new object, that's covered by the
description in the parent section, which also applies to malloc
and friends. (C89/C90 says realloc changes the size of the object,
which is IMHO rather sloppy wording.) Again, the caller can tell
whether realloc(ptr, 0) returned a null pointer or not, and can
safely pass it to free() either way.

C17 adds this (which I missed before):

If size is zero and memory for the new object is not allocated, it
is implementation-defined whether the old object is deallocated.

Presumably for an implementation where malloc(0) returns a null pointer,
this would not apply. But for an implementation where malloc(0) returns
a unique pointer (like malloc(1) except that dereferencing it has
undefined behavior), that allocation might fail.

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

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>
>> [context]
>>
>>>>>> "Catch-23: The New C Standard,Sets the World on Fire"
>>>>>> by Terence Kelly
>>>>>> https://queue.acm.org/detail.cfm?id=3588242
>>
>> [...]
>>
>>> But their example stack code lends itself to a puzzle: on what
>>> implementation assumptions does it depend? I believe it is not
>>> fully portable for reasons that are unrelated to the realloc
>>> implementation. [...]
>>
>> Can you elaborate on this comment? I don't see what you're
>> getting at.
>
> What happens when sizeof int == 1?

Clearly if push() is called when N == SIZE_MAX (which is possible
only if sizeof (int) == 1) then the code misbehaves. To me this
eventuality is more like an unlikely corner case than it is an
implementation assumption. Granted, the misbehavior can occur
only on some implementations, but the problem is that the code is
wrong, not that it has an implementation dependency. That said,
I see now how this situation fits with what you said earlier
mentioning "a puzzle" (although it still feels like the phrase
"implementation assumptions" is more misdirection than it is
something else).

David Brown <david.brown@hesbynett.no> wrote:
> Dan Cross wrote:
>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>
>>> I got the impression they knew that. However, in C89,
>>> realloc(ptr, 0) must behave like free(ptr).
>>> That changed, I think, in C99 with the removal of that
>>> guarantee. There is some evidence that they are little
>>> confused about that guarantee having been lost, thought
>>> of course it is still permitted.
>>
>> Indeed, you are correct. From C89, 7.10.3.3:
>> "if *size* is zero and *ptr* is not a null pointer,
>> the object it points to is freed."
>
> I don't have a C89 reference handy, but I don't think
> realloc(ptr, 0) has ever been required to behave like
> free(ptr). That is one of the allowed behaviours, but
> it is not the only one. In particular, even if it
> first acts like free(ptr), it can then allocate a
> zero-size buffer afterwards. Thus it may not be behaving
> like free(ptr) alone - it can do more. And if you don't
> take that into account, your code will leak memory.

So why all the fuss? If that's an issue for anyone,
they can just write the simplest glue function imaginable,
e.g.,
void *realloc0 ( void *ptr, size_t size ) {
void *reptr = NULL;
if ( size < 1 ) {
if ( ptr != NULL ) free(ptr); }
else reptr = realloc(ptr,size);
return ( reptr ); }
--
John Forkosh ( mailto: j@f.com where j=john and f=forkosh )

In article <86cz4i5cn1.fsf@linuxsc.com>,
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>
>> In article <87zg7n89zw.fsf@bsb.me.uk>,
>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>
>[context]
>
>>>>>> "Catch-23: The New C Standard,Sets the World on Fire"
>>>>>> by Terence Kelly
>>>>>> https://queue.acm.org/detail.cfm?id=3588242
>
>[...]
>
>>> But their example stack code lends itself to a puzzle: on
>>> what implementation assumptions does it depend? I believe it
>>> is not fully portable for reasons that are unrelated to the
>>> realloc implementation. [...]
>
>> The authors, bluntly, wrong: the behavior of realloc() when
>> the size argument is 0, the implementation is, as it always has
>> been since C89, implementation defined.
>
>As noted downthread, that statement isn't right in the particular
>case of C89/C90.

Yes, and this is the third time I'm acknowledging that I was
mistaken about that. :-)

>> [...] The authors tried to make it out like their code was
>> portable and well-defined. [...]
>
>I have to disagree here. The example code is discussed under
>the aegis of what the authors term a "zero-null" allocator
>implementation, where (among other things) 'realloc(p,0)' always
>does a 'free(p)', and will always return NULL. They aren't
>making any claims for any other implementations.

Rereading I can see how you might take it that way, but this is
slicing the thinnest of hairs.

Consider this sentence:

"Imagine, then, my dismay when I learned that C23
declares realloc(ptr,0) to be undefined behavior,
thereby pulling the rug out from under a widespread
and exemplary pattern deliberately condoned by C89
through C11."

Well, no, not exactly. C89 through C11 said that the example
program _may_ work or _may not_, depending on the
implementation, but a perfectly reasonable reader could take the
above statement to mean that it just would.

It goes on:

"So much for stare decisis. Compile idiomatic realloc
code as C23 and the compiler might maul the source
in most astonishing ways and your machine could
ignite at runtime."

Hmm. Idiomatic in whose eyes? Suggesting that the example code
is "idiomatic" further suggests that it is not merely
implementation-dependent, but well-formed in all cases.
Consider the reader here: practitioners. This article is not
the standard, where every word counts.

It is precisely this sort of ambiguity that the committee was
addressing. JeanHyde wrote about this on Twitter:
https://twitter.com/__phantomderp/status/1643698363114610698

- Dan C.

In article <u0kt7r$24ku$1@dont-email.me>,
David Brown <david.brown@hesbynett.no> wrote:
>On 05/04/2023 20:55, Dan Cross wrote:
>> In article <u0k3au$3uelq$1@dont-email.me>,
>> David Brown <david.brown@hesbynett.no> wrote:
>>> On 05/04/2023 15:29, Dan Cross wrote:
>>>> In article <874jpv84uv.fsf@bsb.me.uk>,
>>>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>>
>>>>> I got the impression they knew that. However, in C89, realloc(ptr, 0)
>>>>> must behave like free(ptr). That changed, I think, in C99 with the
>>>>> removal of that guarantee. There is some evidence that they are little
>>>>> confused about that guarantee having been lost, thought of course it is
>>>>> still permitted.
>>>>
>>>> Indeed, you are correct. From C89, 7.10.3.3: "if *size* is zero
>>>> and *ptr* is not a null pointer, the object it points to is
>>>> freed."
>>>
>>> I don't have a C89 reference handy, but I don't think realloc(ptr, 0)
>>> has ever been required to behave like free(ptr). That is one of the
>>> allowed behaviours, but it is not the only one. In particular, even if
>>> it first acts like free(ptr), it can then allocate a zero-size buffer
>>> afterwards. Thus it may not be behaving like free(ptr) alone - it can
>>> do more. And if you don't take that into account, your code will leak
>>> memory.
>>
>> What I quoted above is the actual text from C89. To repeat:
>>
>> "If *size* is zero and *ptr* is not a null pointer,
>> the object it points to is freed."
>>
>> (C89, sec 7.10.3.3.)
>
>I am not disagreeing with that. My point is what happens /after/ the
>pointer ptr is freed. As far as I can tell (and I could be wrong), the
>function can behave in a manner similar to malloc(0) - it can either do
>no allocation and return a null pointer (in which case the whole thing
>is like free(ptr)), or it could allocate a zero-size object and return a
>unique pointer. (Or it could try to do such an allocation, and fail,
>possibly affecting errno.) It is this aspect that is, as far as I can
>tell, implementation dependent and non-portable.

Ah, I see what you mean; the issue is with the composition of
functionality, not a quibble about whether the original pointer
is freed.

I believe you are correct, and I believe the diversity of
implementation opinions (and assumptions in real-world code
based on those opinions) is what caused the commitee to make
this change.

- Dan C.

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>
>>> [context]
>>>
>>>>>>> "Catch-23: The New C Standard,Sets the World on Fire"
>>>>>>> by Terence Kelly
>>>>>>> https://queue.acm.org/detail.cfm?id=3588242
>>>
>>> [...]
>>>
>>>> But their example stack code lends itself to a puzzle: on what
>>>> implementation assumptions does it depend? I believe it is not
>>>> fully portable for reasons that are unrelated to the realloc
>>>> implementation. [...]
>>>
>>> Can you elaborate on this comment? I don't see what you're
>>> getting at.
>>
>> What happens when sizeof int == 1?
>
> Clearly if push() is called when N == SIZE_MAX (which is possible
> only if sizeof (int) == 1) then the code misbehaves. To me this
> eventuality is more like an unlikely corner case than it is an
> implementation assumption. Granted, the misbehavior can occur
> only on some implementations, but the problem is that the code is
> wrong, not that it has an implementation dependency. That said,
> I see now how this situation fits with what you said earlier
> mentioning "a puzzle" (although it still feels like the phrase
> "implementation assumptions" is more misdirection than it is
> something else).

I wouldn't say that the code is wrong. It may never have been written
to be portable and there may even be a static assert or some other test
that checks the assumptions the programmer made. At least that's how I
see it.

--
Ben.

In article <87355d576v.fsf@bsb.me.uk>,
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>[snip]
>> Clearly if push() is called when N == SIZE_MAX (which is possible
>> only if sizeof (int) == 1) then the code misbehaves. To me this
>> eventuality is more like an unlikely corner case than it is an
>> implementation assumption. Granted, the misbehavior can occur
>> only on some implementations, but the problem is that the code is
>> wrong, not that it has an implementation dependency. That said,
>> I see now how this situation fits with what you said earlier
>> mentioning "a puzzle" (although it still feels like the phrase
>> "implementation assumptions" is more misdirection than it is
>> something else).
>
>I wouldn't say that the code is wrong. It may never have been written
>to be portable and there may even be a static assert or some other test
>that checks the assumptions the programmer made. At least that's how I
>see it.

It was presented as _idiomatic_ and representative of an
"exemplary pattern" (the authors words).

They put in a tiny hedge by saying it worked for systems
with "zero-NULL" semantics, but it's clear they thought it
widely applicable.

- Dan C.

cross@spitfire.i.gajendra.net (Dan Cross) writes:

> In article <87355d576v.fsf@bsb.me.uk>,
> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>[snip]
>>> Clearly if push() is called when N == SIZE_MAX (which is possible
>>> only if sizeof (int) == 1) then the code misbehaves. To me this
>>> eventuality is more like an unlikely corner case than it is an
>>> implementation assumption. Granted, the misbehavior can occur
>>> only on some implementations, but the problem is that the code is
>>> wrong, not that it has an implementation dependency. That said,
>>> I see now how this situation fits with what you said earlier
>>> mentioning "a puzzle" (although it still feels like the phrase
>>> "implementation assumptions" is more misdirection than it is
>>> something else).
>>
>>I wouldn't say that the code is wrong. It may never have been written
>>to be portable and there may even be a static assert or some other test
>>that checks the assumptions the programmer made. At least that's how I
>>see it.
>
> It was presented as _idiomatic_ and representative of an
> "exemplary pattern" (the authors words).
>
> They put in a tiny hedge by saying it worked for systems
> with "zero-NULL" semantics, but it's clear they thought it
> widely applicable.

I /would/ call that aspect as wrong. It's a awful use of realloc. I
was addressing another issue (the failure when sizeof int == 1) which
Tim considered a corner case, and I saw as an assumption about the
implementation.

--
Ben.

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>
>>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>>
>>>> [context]
>>>>
>>>>>>>> "Catch-23: The New C Standard,Sets the World on Fire"
>>>>>>>> by Terence Kelly
>>>>>>>> https://queue.acm.org/detail.cfm?id=3588242
>>>>
>>>> [...]
>>>>
>>>>> But their example stack code lends itself to a puzzle: on what
>>>>> implementation assumptions does it depend? I believe it is not
>>>>> fully portable for reasons that are unrelated to the realloc
>>>>> implementation. [...]
>>>>
>>>> Can you elaborate on this comment? I don't see what you're
>>>> getting at.
>>>
>>> What happens when sizeof int == 1?
>>
>> Clearly if push() is called when N == SIZE_MAX (which is possible
>> only if sizeof (int) == 1) then the code misbehaves. To me this
>> eventuality is more like an unlikely corner case than it is an
>> implementation assumption. Granted, the misbehavior can occur
>> only on some implementations, but the problem is that the code is
>> wrong, not that it has an implementation dependency. That said,
>> I see now how this situation fits with what you said earlier
>> mentioning "a puzzle" (although it still feels like the phrase
>> "implementation assumptions" is more misdirection than it is
>> something else).
>
> I wouldn't say that the code is wrong. It may never have been
> written to be portable and there may even be a static assert or
> some other test that checks the assumptions the programmer made.
> At least that's how I see it.

I don't disagree. My use of "wrong" was informal. A better
phrasing is that as it stands the code has a potential defect.
Moreover the defect is in push(), not in the resize() function.
At the very least push() could use an 'assert( N < SIZE_MAX )',
or something like it, before calling 'resize(N+1)'.

On 06/04/2023 07:42, John Forkosh wrote:
> David Brown <david.brown@hesbynett.no> wrote:
>> Dan Cross wrote:
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>
>>>> I got the impression they knew that. However, in C89,
>>>> realloc(ptr, 0) must behave like free(ptr).
>>>> That changed, I think, in C99 with the removal of that
>>>> guarantee. There is some evidence that they are little
>>>> confused about that guarantee having been lost, thought
>>>> of course it is still permitted.
>>>
>>> Indeed, you are correct. From C89, 7.10.3.3:
>>> "if *size* is zero and *ptr* is not a null pointer,
>>> the object it points to is freed."
>>
>> I don't have a C89 reference handy, but I don't think
>> realloc(ptr, 0) has ever been required to behave like
>> free(ptr). That is one of the allowed behaviours, but
>> it is not the only one. In particular, even if it
>> first acts like free(ptr), it can then allocate a
>> zero-size buffer afterwards. Thus it may not be behaving
>> like free(ptr) alone - it can do more. And if you don't
>> take that into account, your code will leak memory.
>
> So why all the fuss? If that's an issue for anyone,
> they can just write the simplest glue function imaginable,
> e.g.,
> void *realloc0 ( void *ptr, size_t size ) {
> void *reptr = NULL;
> if ( size < 1 ) {
> if ( ptr != NULL ) free(ptr); }
> else reptr = realloc(ptr,size);
> return ( reptr ); }
>

Well, yes, that would seem the sensible solution. If you want code to
be reasonably portable, you have to avoid implementation-dependent
behaviour like this, especially when implementations vary so widely in
their details and we are talking about easily detectable corner cases.

On 2023-04-06, John Forkosh <forkosh@panix.com> wrote:
> void *realloc0 ( void *ptr, size_t size ) {
> void *reptr = NULL;
> if ( size < 1 ) {

That's a silly way to spell size == 0, when size is an
unsigned type, which size_t is required to be.

The special case we want to handle is when size is zero, so
test for that, rather that by an indirect inequality that
mentions a different, irrelevant value.

> if ( ptr != NULL ) free(ptr); }

This check is pointless; free is required to work on null pointers.

> else reptr = realloc(ptr,size);
> return ( reptr ); }

Consider:

return (size == 0) ? free(ptr), NULL : realloc(ptr, size);

which avoids multiple returns, variable assignment, and
verbiage.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On Wednesday, 5 April 2023 at 20:23:42 UTC+1, Ben Bacarisse wrote:
> Tim Rentsch <tr.1...@z991.linuxsc.com> writes:
>
> > Ben Bacarisse <ben.u...@bsb.me.uk> writes:
> >
> > [context]
> >
> >>>>> "Catch-23: The New C Standard,Sets the World on Fire"
> >>>>> by Terence Kelly
> >>>>> https://queue.acm.org/detail.cfm?id=3588242
> >
> > [...]
> >
> >> But their example stack code lends itself to a puzzle: on what
> >> implementation assumptions does it depend? I believe it is not
> >> fully portable for reasons that are unrelated to the realloc
> >> implementation. [...]
> >
> > Can you elaborate on this comment? I don't see what you're
> > getting at.
> What happens when sizeof int == 1?
>
int *s;
if (nu > SIZE_MAX / sizeof *s)

will fail. Well spotted.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> On Wednesday, 5 April 2023 at 20:23:42 UTC+1, Ben Bacarisse wrote:
>> Tim Rentsch <tr.1...@z991.linuxsc.com> writes:
>>
>> > Ben Bacarisse <ben.u...@bsb.me.uk> writes:
>> >
>> > [context]
>> >
>> >>>>> "Catch-23: The New C Standard,Sets the World on Fire"
>> >>>>> by Terence Kelly
>> >>>>> https://queue.acm.org/detail.cfm?id=3588242
>> >
>> > [...]
>> >
>> >> But their example stack code lends itself to a puzzle: on what
>> >> implementation assumptions does it depend? I believe it is not
>> >> fully portable for reasons that are unrelated to the realloc
>> >> implementation. [...]
>> >
>> > Can you elaborate on this comment? I don't see what you're
>> > getting at.
>> What happens when sizeof int == 1?
>>
> int *s;
> if (nu > SIZE_MAX / sizeof *s)
>
> will fail. Well spotted.

It's not clear where the mistake is. When sizeof int == 1, it's fine to
request nu == SIZE_MAX slots, so in some sense, the test is correct!
Considered like this, the error is in push when it asks for N+1 slots,
because N+1 will then be 0. Once push has passed 0, no test in resize
can fix it.

--
Ben.

cross@spitfire.i.gajendra.net (Dan Cross) writes:

> In article <86cz4i5cn1.fsf@linuxsc.com>,
> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> cross@spitfire.i.gajendra.net (Dan Cross) writes:
>>
>>> In article <87zg7n89zw.fsf@bsb.me.uk>,
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>
>> [context]
>>
>>>>>>> "Catch-23: The New C Standard,Sets the World on Fire"
>>>>>>> by Terence Kelly
>>>>>>> https://queue.acm.org/detail.cfm?id=3588242
>>
>> [...]
>>
>>>> But their example stack code lends itself to a puzzle: on
>>>> what implementation assumptions does it depend? I believe it
>>>> is not fully portable for reasons that are unrelated to the
>>>> realloc implementation. [...]
>>>
>>> The authors, bluntly, wrong: the behavior of realloc() when
>>> the size argument is 0, the implementation is, as it always has
>>> been since C89, implementation defined.
>>
>> As noted downthread, that statement isn't right in the particular
>> case of C89/C90.
>
> Yes, and this is the third time I'm acknowledging that I was
> mistaken about that. :-)

My comment was meant to acknowledge that you had already
recognized this, not to flog you for it. Sorry for the
confusion.

>>> [...] The authors tried to make it out like their code was
>>> portable and well-defined. [...]
>>
>> I have to disagree here. The example code is discussed under
>> the aegis of what the authors term a "zero-null" allocator
>> implementation, where (among other things) 'realloc(p,0)' always
>> does a 'free(p)', and will always return NULL. They aren't
>> making any claims for any other implementations.
>
> Rereading I can see how you might take it that way, but this is
> slicing the thinnest of hairs.
>
> Consider this sentence:
>
> "Imagine, then, my dismay when I learned that C23
> declares realloc(ptr,0) to be undefined behavior,
> thereby pulling the rug out from under a widespread
> and exemplary pattern deliberately condoned by C89
> through C11."
>
> Well, no, not exactly. [...]

I think you misunderstood my comment. I didn't mean to say
anything about what the authors say about the evolution of
realloc(). I meant only that the code they gave works just fine
(not counting the problem when 'sizeof (int) == 1' that Ben B
pointed out) -- importantly, under the assumptions that the
authors explicitly stated -- and that they didn't say anything
about whether the code is portable or well-defined if considered
outside of those assumptions. The authors may have some opinions
about whether the code /should/ work in general, but they don't
make any claims about whether it /does/ work in general, and that
point is the only one I mean to address.