I'm looking at the C99 and N3096 (April 2023) definitions of realloc
side by side.

N3096 says

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

Yikes! In C99 there is nothing about the size being zero:

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

Nothing about "or if the size is zero".

Yikes; when did this criminal stupidity get perpetrated?

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On Wed, 17 Jan 2024 00:32:10 -0000 (UTC), Kaz Kylheku wrote:

> Nothing about "or if the size is zero".

From <https://manpages.debian.org/3/realloc.en.html>:

If size is equal to zero, and ptr is not NULL, then the call is
equivalent to free(ptr) (but see "Nonportable behavior" for
portability issues).

And from the referenced section:

The behavior of these functions when the requested size is zero is
glibc specific; other implementations may return NULL without setting
errno, and portable POSIX programs should tolerate such behavior.

On 2024-01-17, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Wed, 17 Jan 2024 00:32:10 -0000 (UTC), Kaz Kylheku wrote:
>
>> Nothing about "or if the size is zero".
>
> From <https://manpages.debian.org/3/realloc.en.html>:
>
> If size is equal to zero, and ptr is not NULL, then the call is
> equivalent to free(ptr) (but see "Nonportable behavior" for
> portability issues).

That is just garbage documentation though. No case in realloc
is equivalent to just free(ptr) and nothing else.

> And from the referenced section:
>
> The behavior of these functions when the requested size is zero is
> glibc specific; other implementations may return NULL without setting
> errno, and portable POSIX programs should tolerate such behavior.

None of those choices is simply "undefined behavior". This is just the
old concept that implementations may have malloc(0) returning null, or
else allocate a unique pointer that can be liberated via free.

Previously, realloc(ptr, 0) behaved like free(ptr) followed by
returning the result of malloc(0).

What we see in N3096 is that this resize to zero is undefined behavior,
while malloc(0) remains well-defined.

Thus applications which previously relied on that case of realloc
now have to do this:

void *classic_realloc(void *ptr, size_t size)
{
// Handle zero size case as was required in C99,
// thereby avoiding undefined behavior.

if (size == 0) {
free(ptr);
return malloc(0);
}

// Pass other cases to realloc.
return realloc(ptr, size);
}

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On Wed, 17 Jan 2024 02:32:41 -0000 (UTC), Kaz Kylheku wrote:

> That is just garbage documentation though.

You’re talking about what the C spec says, I’m talking about POSIX.

On 2024-01-17, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Wed, 17 Jan 2024 02:32:41 -0000 (UTC), Kaz Kylheku wrote:
>
>> That is just garbage documentation though.
>
> You’re talking about what the C spec says, I’m talking about POSIX.

Oh, I'm sorry, am I in the wrong newsgroup?

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On Wed, 17 Jan 2024 03:08:22 -0000 (UTC), Kaz Kylheku wrote:

> Oh, I'm sorry, am I in the wrong newsgroup?

No need to apologize, just leave quietly.

On 17/01/2024 01:32, Kaz Kylheku wrote:
> I'm looking at the C99 and N3096 (April 2023) definitions of realloc
> side by side.
>
> N3096 says
>
> "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."
>
> Yikes! In C99 there is nothing about the size being zero:
>
> "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."
>
> Nothing about "or if the size is zero".
>
> Yikes; when did this criminal stupidity get perpetrated?
>

Nothing stops a particular library implementation from giving this all a
defined behaviour. It was already "implementation defined" - if you
want to be able to use malloc or realloc with size 0, then you need to
know exactly how your library says it will behave or your code will risk
serious problems.

While I don't know why this change was made, and I agree it sounds a
strange change to make, I cannot see how any code would be affected by
it. Either your code is non-portable and relies on specific behaviour
(documented by your particular library, or additional standards such as
POSIX), or it has portability issues that could lead to failures if it
is used with a library that doesn't match your guessed behaviour - the C
standards making this UB does not change anything.

All this means, in my eyes, is that developers are being encouraged to
take responsibility for size zero allocations in their own code - make
an active choice about how they will deal with it (if it can occur in
their code). After all, there is no single appropriate choice of
behaviour for malloc or realloc of zero size - the best way to handle it
will depend on the user program.

Kaz Kylheku <433-929-6894@kylheku.com> writes:
>I'm looking at the C99 and N3096 (April 2023) definitions of realloc
>side by side.
>
>N3096 says
>
>"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."
>
>Yikes! In C99 there is nothing about the size being zero:
>
>"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."
>
>Nothing about "or if the size is zero".
>
>Yikes; when did this criminal stupidity get perpetrated?

I'm not sure what stupidity you are referring to, but IIRC, there was
some recent standardization activity relating to realloc
when size == 0 because there were differences in the behavior
between different implementations. Making the behavior
undefined was the only rational choice.

On 2024-01-17, David Brown <david.brown@hesbynett.no> wrote:
> On 17/01/2024 01:32, Kaz Kylheku wrote:
>> Yikes; when did this criminal stupidity get perpetrated?
>>
>
> Nothing stops a particular library implementation from giving this all a
> defined behaviour.

Nothings stops getchar() from being locally defined as an extension;
let's make it undefined behavior!

An entire language can be defined by an implementation, with no
standard.

People use plenty of these and tech marches on.

> It was already "implementation defined" - if you
> want to be able to use malloc or realloc with size 0, then you need to
> know exactly how your library says it will behave or your code will risk
> serious problems.

No, not serious. Very minor problems in a rare combination of
circumstances.

It's possible that realloc(ptr, 0) will return null, and this null
indicates that the reallocation failed due to OOM, meaning that ptr is
still valid.

This situation is indistinguishable from ptr having been freed,
and the null just being the result of a working zero size allocation.

(Implementations can easily resolve the ambiguity internally and
guarantee that realloc(ptr, 0) will free the object, and not
leak ptr.)

> While I don't know why this change was made, and I agree it sounds a
> strange change to make, I cannot see how any code would be affected by
> it. Either your code is non-portable and relies on specific behaviour
> (documented by your particular library, or additional standards such as
> POSIX), or it has portability issues that could lead to failures if it
> is used with a library that doesn't match your guessed behaviour - the C
> standards making this UB does not change anything.

It isn't nonportable. Dynamic array management code can resize an object
down to zero (as an alternative to freeing it). There is no problem with
this (other than the possible ambiguity under OOM conditions). In the
abstract semantics, the old object is freed, and you get a new one as if
from malloc(0).

Code can easily be written not to care whether malloc(0) returns null
or non-null.

> All this means, in my eyes, is that developers are being encouraged to
> take responsibility for size zero allocations in their own code - make

Working code that relies on zero size allocations already (even if
that isn't the best alternative in that code) won't fix itself to become
defined again.

> an active choice about how they will deal with it (if it can occur in
> their code). After all, there is no single appropriate choice of
> behaviour for malloc or realloc of zero size - the best way to handle it
> will depend on the user program.

A malloc of zero size is still defined; only realloc to zero size is
no longer defined. If you pretend that the remark about size zero isn't
there in the description of realloc, the rest of the description of
realloc still says that the old object will be freed, and the new one
will come as if from a malloc request for that size.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 2024-01-17, Scott Lurndal <scott@slp53.sl.home> wrote:
> Kaz Kylheku <433-929-6894@kylheku.com> writes:
>>Yikes; when did this criminal stupidity get perpetrated?
>
> I'm not sure what stupidity you are referring to, but IIRC, there was
> some recent standardization activity relating to realloc
> when size == 0 because there were differences in the behavior
> between different implementations. Making the behavior
> undefined was the only rational choice.

No, the rational choice is letting those implementations be
nonconforming, until they fix their shit.

You cannot claw back decades-old defined behaviors in a major
language standard because some players are getting it wrong
in some way.

I now have to do things like this in all the code I work on:

void *sane_realloc(void *ptr, size_t size)
{
if (size == 0) {
free(ptr);
return malloc(0); // don't care if that didn't work
}
return realloc(ptr, size);
}
or, if I don't suspect realloc-to-zero is being used:

void *sane_realloc(void *ptr, size_t size)
{
assert (size != 0);
return realloc(ptr, size);
}

and this is code that will never even run on those rogue implementations
whose botchery lead to the poor decision of the language being damaged.

Any implementation of realloc whatsoever could just do this internally:

void *realloc(void *ptr, size_t size)
{
if (size == 0) {
__free(ptr);
return __malloc(0);
}
// call our internal __realloc implementation that
// we suspect doesn't handle zero.
return __realloc(ptr, size);
}

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 1/17/2024 11:47 AM, Kaz Kylheku wrote:
> On 2024-01-17, David Brown <david.brown@hesbynett.no> wrote:
>> On 17/01/2024 01:32, Kaz Kylheku wrote:
>>> Yikes; when did this criminal stupidity get perpetrated?
>>>
>>
>> Nothing stops a particular library implementation from giving this all a
>> defined behaviour.
>
> Nothings stops getchar() from being locally defined as an extension;
> let's make it undefined behavior!
>
> An entire language can be defined by an implementation, with no
> standard.
>
> People use plenty of these and tech marches on.
>

And then Clang goes and decides to make any use of these functions cause
the whole control-flow path to be pruned from existence or something...
Since, after all, it is UB...

( Partly satire, but wouldn't exactly be surprised... )

>> It was already "implementation defined" - if you
>> want to be able to use malloc or realloc with size 0, then you need to
>> know exactly how your library says it will behave or your code will risk
>> serious problems.
>
> No, not serious. Very minor problems in a rare combination of
> circumstances.
>
> It's possible that realloc(ptr, 0) will return null, and this null
> indicates that the reallocation failed due to OOM, meaning that ptr is
> still valid.
>
> This situation is indistinguishable from ptr having been freed,
> and the null just being the result of a working zero size allocation.
>
> (Implementations can easily resolve the ambiguity internally and
> guarantee that realloc(ptr, 0) will free the object, and not
> leak ptr.)
>

Yeah, find something sensible to do and do it.
Knowing modern compilers, declaring anything as UB throws a big wrench
into things.

>> While I don't know why this change was made, and I agree it sounds a
>> strange change to make, I cannot see how any code would be affected by
>> it. Either your code is non-portable and relies on specific behaviour
>> (documented by your particular library, or additional standards such as
>> POSIX), or it has portability issues that could lead to failures if it
>> is used with a library that doesn't match your guessed behaviour - the C
>> standards making this UB does not change anything.
>
> It isn't nonportable. Dynamic array management code can resize an object
> down to zero (as an alternative to freeing it). There is no problem with
> this (other than the possible ambiguity under OOM conditions). In the
> abstract semantics, the old object is freed, and you get a new one as if
> from malloc(0).
>
> Code can easily be written not to care whether malloc(0) returns null
> or non-null.
>

Yes.

>> All this means, in my eyes, is that developers are being encouraged to
>> take responsibility for size zero allocations in their own code - make
>
> Working code that relies on zero size allocations already (even if
> that isn't the best alternative in that code) won't fix itself to become
> defined again.
>
>> an active choice about how they will deal with it (if it can occur in
>> their code). After all, there is no single appropriate choice of
>> behaviour for malloc or realloc of zero size - the best way to handle it
>> will depend on the user program.
>
> A malloc of zero size is still defined; only realloc to zero size is
> no longer defined. If you pretend that the remark about size zero isn't
> there in the description of realloc, the rest of the description of
> realloc still says that the old object will be freed, and the new one
> will come as if from a malloc request for that size.
>

Agreed.

My personal preference is that behaviors be kept "sensible" when possible.

At least in my own compiler, I generally try for sensible behaviors.
But, within the limit that the compiler may also be buggy...

Finding and fixing bugs is a priority, but as I see it, things like
optimization concerns (or esoteric edge cases) should not be
justification for deviating from otherwise sensible behavior (and
instead limited to cases that would not otherwise be visible to the
program in question).

Granted, I would also prefer it if compilers were not allowed to make
optimizations which may change the visible behavior of a program (at
least within "sane" limits) but, alas... ( Say, we put the burden of
proof on the compiler that an optimization does not change the visible
output or behavior of the program. ).

Kaz Kylheku <433-929-6894@kylheku.com> writes:
>On 2024-01-17, Scott Lurndal <scott@slp53.sl.home> wrote:
>> Kaz Kylheku <433-929-6894@kylheku.com> writes:
>>>Yikes; when did this criminal stupidity get perpetrated?
>>
>> I'm not sure what stupidity you are referring to, but IIRC, there was
>> some recent standardization activity relating to realloc
>> when size == 0 because there were differences in the behavior
>> between different implementations. Making the behavior
>> undefined was the only rational choice.
>
>No, the rational choice is letting those implementations be
>nonconforming, until they fix their shit.
>
>You cannot claw back decades-old defined behaviors in a major

Nobody is clawing anything back. No compiler is going to
change its behavior because undefined behavior is now
called undefined behavior.

Everything that's been done for decades will still work just
fine.

Realloc with a length zero - never - made any sense anyway.

>language standard because some players are getting it wrong
>in some way.
>
>I now have to do things like this in all the code I work on:
>
> void *sane_realloc(void *ptr, size_t size)
> {
> if (size == 0) {
> free(ptr);
> return malloc(0); // don't care if that didn't work
> }
> return realloc(ptr, size);
> }

You can also just never call sane_realloc with a size of zero.

On 2024-01-17, Scott Lurndal <scott@slp53.sl.home> wrote:
> Kaz Kylheku <433-929-6894@kylheku.com> writes:
>>On 2024-01-17, Scott Lurndal <scott@slp53.sl.home> wrote:
>>> Kaz Kylheku <433-929-6894@kylheku.com> writes:
>>>>Yikes; when did this criminal stupidity get perpetrated?
>>>
>>> I'm not sure what stupidity you are referring to, but IIRC, there was
>>> some recent standardization activity relating to realloc
>>> when size == 0 because there were differences in the behavior
>>> between different implementations. Making the behavior
>>> undefined was the only rational choice.
>>
>>No, the rational choice is letting those implementations be
>>nonconforming, until they fix their shit.
>>
>>You cannot claw back decades-old defined behaviors in a major
>
> Nobody is clawing anything back. No compiler is going to
> change its behavior because undefined behavior is now
> called undefined behavior.

What? The behavior was defined in the absence of the new piece of text
saying that the behavior of realloc is arbitrarily undefined when size
is zero.

> Everything that's been done for decades will still work just
> fine.

Even if nothing changes in the library implementation of realloc, a
highly optimizing compiler can now treat everything after a realloc(ptr,
0) as unreachable code:

void f(void *p)
{
realloc(p, 0);
}

This function can be compiled the same as:

void f(void *p)
{
__builtin_unreachable();
}

This is not something that the library people can keep fully working by
simply not messing with realloc.

> Realloc with a length zero - never - made any sense anyway.

Yes it does; in a dynamic vector type, you can tell the thing to resize
to zero size. If that API is implemented with realloc, it now has
undefined behavior according to n3096.

>>language standard because some players are getting it wrong
>>in some way.
>>
>>I now have to do things like this in all the code I work on:
>>
>> void *sane_realloc(void *ptr, size_t size)
>> {
>> if (size == 0) {
>> free(ptr);
>> return malloc(0); // don't care if that didn't work
>> }
>> return realloc(ptr, size);
>> }
>
> You can also just never call sane_realloc with a size of zero.

That could be more work. You have to identify what does that,
if anything, and fix it.

If your project already has a wrapper for realloc, it's easy
to fix it there.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

It looks to me like it was always undefined behavior, but it just wasn't
explicitly stated as such in C99. Undefined behavior does not require the
specification to explictly state that the behavior is not defined; it just
has to provide no definition for it.

--
Blue-Maned_Hawk│shortens to
Hawk│/
blu.mɛin.dÊ°ak/
│he/him/his/himself/Mr.
blue-maned_hawk.srht.site
Atlanta makes it against the law to tie a giraffe to a street lamp or
telephone pole.

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);
void *q = realloc(p, 0);

The p object is freed, and a new object q is obtained as if by
malloc(0). q may be null, or else a pointer to a unique object
that can be freed.

q and p could possibly point to the same address; just like in
a non-zero-sized realloc call.

> Undefined behavior does not require the
> specification to explictly state that the behavior is not defined; it just
> has to provide no definition for it.

A definition is provided by virtue of the size 0 not being special in
any way in realloc. It's defined because the behavior for size 1 is
defined, as for size 2, ...

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> writes:

> It looks to me like it was always undefined behavior, but it just wasn't
> explicitly stated as such in C99. Undefined behavior does not require the
> specification to explictly state that the behavior is not defined; it just
> has to provide no definition for it.

You are mistaken. The C99 standard, and also the C11 standard,
plainly state that such requests give implementation-defined
behavior:

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.

Kaz Kylheku <433-929-6894@kylheku.com> writes:

> 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);
> void *q = realloc(p, 0);
>
> The p object is freed, and a new object q is obtained as if by
> malloc(0). q may be null, or else a pointer to a unique object
> that can be freed.
>
> q and p could possibly point to the same address; just like in
> a non-zero-sized realloc call.
>
>> Undefined behavior does not require the
>> specification to explictly state that the behavior is not defined; it just
>> has to provide no definition for it.
>
> A definition is provided by virtue of the size 0 not being special in
> any way in realloc. It's defined because the behavior for size 1 is
> defined, as for size 2, ...

Actually, a size of 0 is specifically stated as implementation-defined
behavior, in section 7.20.3, paragraph 1 (in N1256), which applies to
all the memory allocation functions, realloc() included.

Kaz Kylheku <433-929-6894@kylheku.com> writes:

> I'm looking at the C99 and N3096 (April 2023) definitions of realloc
> side by side.
>
> N3096 says
>
> "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."
>
> Yikes! In C99 there is nothing about the size being zero:
>
> "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."
>
> Nothing about "or if the size is zero".
>
> Yikes; when did this criminal stupidity get perpetrated?

I guess you missed the thread from a little while back when
this change was discussed.

During that conversation, I was in complete agreement with
your reaction as stated above. Moreover nothing that has
come to light in the meantime that gives me any reason to
think otherwise.

scott@slp53.sl.home (Scott Lurndal) writes:

> Kaz Kylheku <433-929-6894@kylheku.com> writes:
>
>> I'm looking at the C99 and N3096 (April 2023) definitions of realloc
>> side by side.
>>
>> N3096 says
>>
>> "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."
>>
>> Yikes! In C99 there is nothing about the size being zero:
>>
>> "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."
>>
>> Nothing about "or if the size is zero".
>>
>> Yikes; when did this criminal stupidity get perpetrated?
>
> I'm not sure what stupidity you are referring to, but IIRC, there was
> some recent standardization activity relating to realloc
> when size == 0 because there were differences in the behavior
> between different implementations. Making the behavior
> undefined was the only rational choice.

Is that last sentence your own assessment, or are you simply
repeating someone else's assessment?

On Wed, 17 Jan 2024 17:35:38 -0800, Tim Rentsch wrote:

> The C99 standard, and also the C11 standard,
> plainly state that such requests give implementation-defined behavior:
>
> 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.

Still, most of us use C on more reasonable, POSIX-type systems, where the
behaviour is somewhat better defined.

On 2024-01-18, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Wed, 17 Jan 2024 17:35:38 -0800, Tim Rentsch wrote:
>
>> The C99 standard, and also the C11 standard,
>> plainly state that such requests give implementation-defined behavior:
>>
>> 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.
>
> Still, most of us use C on more reasonable, POSIX-type systems, where the
> behaviour is somewhat better defined.

No, it isn't. The above wording is exactly the same in POSIX:

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

https://pubs.opengroup.org/onlinepubs/9699919799/functions/realloc.html

If you find the behavior better defined in your POSIX system, it's
not because of POSIX.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On Thu, 18 Jan 2024 05:59:08 -0000 (UTC), Kaz Kylheku wrote:

> If you find the behavior better defined in your POSIX system, it's not
> because of POSIX.

From <https://manpages.debian.org/3/realloc.en.html>:

If size is equal to zero, and ptr is not NULL, then the call is
equivalent to free(ptr) (but see "Nonportable behavior" for
portability issues).

And from the referenced section:

The behavior of these functions when the requested size is zero is
glibc specific; other implementations may return NULL without setting
errno, and portable POSIX programs should tolerate such behavior.

GNU-specific, then.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

> On Wed, 17 Jan 2024 17:35:38 -0800, Tim Rentsch wrote:
>
>> The C99 standard, and also the C11 standard,
>> plainly state that such requests give implementation-defined behavior:
>>
>> 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.
>
> Still, most of us use C on more reasonable, POSIX-type systems, where the
> behaviour is somewhat better defined.

You say that like you think your statement has some relevance to
the issue being discussed. It doesn't.

scott@slp53.sl.home (Scott Lurndal) writes:

> Kaz Kylheku <433-929-6894@kylheku.com> writes:
>
>> On 2024-01-17, Scott Lurndal <scott@slp53.sl.home> wrote:
>>
>>> Kaz Kylheku <433-929-6894@kylheku.com> writes:
>>>
>>>> Yikes; when did this criminal stupidity get perpetrated?
>>>
>>> I'm not sure what stupidity you are referring to, but IIRC, there was
>>> some recent standardization activity relating to realloc
>>> when size == 0 because there were differences in the behavior
>>> between different implementations. Making the behavior
>>> undefined was the only rational choice.
>>
>> No, the rational choice is letting those implementations be
>> nonconforming, until they fix their shit.
>>
>> You cannot claw back decades-old defined behaviors in a major
>
> Nobody is clawing anything back. [...]

This statement seems directly contradicted by the proposed
modification to the C standard, which changes previously
defined behavior to undefined behavior.

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>scott@slp53.sl.home (Scott Lurndal) writes:
>
>> Kaz Kylheku <433-929-6894@kylheku.com> writes:
>>
>>> I'm looking at the C99 and N3096 (April 2023) definitions of realloc
>>> side by side.
>>>
>>> N3096 says
>>>
>>> "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."
>>>
>>> Yikes! In C99 there is nothing about the size being zero:
>>>
>>> "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."
>>>
>>> Nothing about "or if the size is zero".
>>>
>>> Yikes; when did this criminal stupidity get perpetrated?
>>
>> I'm not sure what stupidity you are referring to, but IIRC, there was
>> some recent standardization activity relating to realloc
>> when size == 0 because there were differences in the behavior
>> between different implementations. Making the behavior
>> undefined was the only rational choice.
>
>Is that last sentence your own assessment, or are you simply
>repeating someone else's assessment?

My assessment. I've never found realloc useful, regardless of
the value of the size parameter. YMMV.