"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

"The Good News

A new major revision of the C language standard, C23, is due out this
year. We'll tour the highs and lows of the latest draft9 and then drill
down on the mother of all breaking changes. Sidebars celebrate C idioms
and undefined behavior with code and song, respectively."

"Unfilled Potholes and Festering Sores

Laws should be freely available, intelligible, and agreeable to the
governed, and they should keep pace with changing times. C23 lacks these
virtues."

Wow.

Lynn

On 04/04/2023 00:20, Lynn McGuire 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
>

The same document in pdf format:

<https://dl.acm.org/doi/pdf/10.1145/3588242>

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.

In article <u0fn0g$34scf$1@dont-email.me>,
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
>[snip]

Yikes. That article is truly awful.

ACM should be ashamed.

- Dan C.

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?

--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/Snicker

gazelle@shell.xmission.com (Kenny McCormack) writes:
>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?

A fatal change in the semantics of 'realloc'.

On 4/3/2023 10:00 PM, Jim Kelly wrote:
> On 04/04/2023 00:20, Lynn McGuire 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
>>
>
> The same document in pdf format:
>
> <https://dl.acm.org/doi/pdf/10.1145/3588242>

Thanks, I should have added that also.

Lynn

On 4/4/2023 6:30 AM, Dan Cross wrote:
> In article <u0fn0g$34scf$1@dont-email.me>,
> 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
>> [snip]
>
> Yikes. That article is truly awful.
>
> ACM should be ashamed.
>
> - Dan C.

Written by real programmers, not journalists. What do you expect ? Not
everyone is Donald Knuth or Niklaus Wirth.

Lynn

Lynn McGuire <lynnmcguire5@gmail.com> writes:

> On 4/4/2023 6:30 AM, Dan Cross wrote:
>> In article <u0fn0g$34scf$1@dont-email.me>,
>> 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
>>> [snip]
>> Yikes. That article is truly awful.
>> ACM should be ashamed.
>> - Dan C.
>
> Written by real programmers, not journalists. What do you expect ? Not
> everyone is Donald Knuth or Niklaus Wirth.

I would expect a more serious tone from an ACM publication, but the
journal (ACMQUEUE) is one I don't know and it may well have a more
relaxed editorial policy than I am used to. I don't like hyperbole and
sarcasm in technical publications but I am not "down with the kids"
these days.

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.
This is not, technically speaking, a bug since I have no reason to
suppose the code was intended to be portable across all conforming C
implementations, but I'd have pointed it out, had I been a reviewer,
since it's an unnecessary distraction to the reader.

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.

--
Ben.

In article <87zg7n89zw.fsf@bsb.me.uk>,
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>Lynn McGuire <lynnmcguire5@gmail.com> writes:
>
>> On 4/4/2023 6:30 AM, Dan Cross wrote:
>>> In article <u0fn0g$34scf$1@dont-email.me>,
>>> 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
>>>> [snip]
>>> Yikes. That article is truly awful.
>>> ACM should be ashamed.
>>> - Dan C.
>>
>> Written by real programmers, not journalists. What do you expect ? Not
>> everyone is Donald Knuth or Niklaus Wirth.
>
>I would expect a more serious tone from an ACM publication, but the
>journal (ACMQUEUE) is one I don't know and it may well have a more
>relaxed editorial policy than I am used to. I don't like hyperbole and
>sarcasm in technical publications but I am not "down with the kids"
>these days.
>
>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.
>This is not, technically speaking, a bug since I have no reason to
>suppose the code was intended to be portable across all conforming C
>implementations, but I'd have pointed it out, had I been a reviewer,
>since it's an unnecessary distraction to the reader.
>
>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. Moreoever, there's no
way to tell whether the underlying object was actually free'd or
not from the return alone, and checking `errno` is not portable.
The proposal to make realloc with size 0 UB is not bad here:
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2464.pdf

The authors tried to make it out like their code was portable
and well-defined. It was not.

That combined with the little quips about "neurodivergent" ideas
or about marijuana legalization (really?) smack of proud
ignorance. That they can't understand at all what `unreachable`
may be used for makes me think that they may not have as good of
a handle on the language as they claim.

Oh, and among the people championing having `malloc(0)` return a
non-NULL pointer were Rob Pike and Doug McIlroy. Not that one
need appeal to authority, but the article's authors would have
done well to at least, perhaps, listen to some of the viewpoints
of folks from the lab where C was born before pouring derision
on ideas that they didn't seem to have a great understanding of.

- Dan C.

Le 05/04/2023 à 02:42, Dan Cross a écrit :
> 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.

Yes, it's actually the case for all memory allocation functions (malloc,
calloc, realloc):
" 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."

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

Indeed. If you use implementationd-defined behaviors, you should know
what to expect and document it appropriately. Do not expect it to still
be doing what you expected with any other implementation.

I've personally never used this implementation-defined behavior and try
to avoid all of them in general as much as is practical.

> That combined with the little quips about "neurodivergent" ideas
> or about marijuana legalization (really?) smack of proud
> ignorance. That they can't understand at all what `unreachable`
> may be used for makes me think that they may not have as good of
> a handle on the language as they claim.

It read a bit like a tantrum with a clickbaity title.

> Oh, and among the people championing having `malloc(0)` return a
> non-NULL pointer were Rob Pike and Doug McIlroy. Not that one
> need appeal to authority, but the article's authors would have
> done well to at least, perhaps, listen to some of the viewpoints
> of folks from the lab where C was born before pouring derision
> on ideas that they didn't seem to have a great understanding of.

malloc(0) has the same behavior as realloc(xx, 0) as I quoted above.
The behavior is implementation-defined, and even when it does not return
a null pointer, you're not supposed to dereference it.

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

> Lynn McGuire <lynnmcguire5@gmail.com> writes:
>
>> On 4/4/2023 6:30 AM, Dan Cross wrote:
>>> In article <u0fn0g$34scf$1@dont-email.me>,
>>> 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
>>>> [snip]
>>> Yikes. That article is truly awful.
>>> ACM should be ashamed.
>>> - Dan C.
>>
>> Written by real programmers, not journalists. What do you expect ? Not
>> everyone is Donald Knuth or Niklaus Wirth.
>
> I would expect a more serious tone from an ACM publication, but the
> journal (ACMQUEUE) is one I don't know and it may well have a more
> relaxed editorial policy than I am used to. I don't like hyperbole and
> sarcasm in technical publications but I am not "down with the kids"
> these days.

Queue is Not An Academic Journal. Because, apparently, working software
professionals never read academic journals, so it's critical to make
clear that they aren't one.

Not that they're necessarily all that wrong.

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

I think they're saying that before C17, realloc to a size of zero was
implementation defined, and that C17 changed that to it being
undefined. That isn't quite right, because it was implementation-defined
both before and after. But (I think; I don't have a full copy of C17 at
hand) the limitations were changed, and realloc to a size of zero was
explicitly described as obsolescent. Unless I'm mistaken factually
(possible, as I mentioned) I think it's reasonable to consider
C17 to be moving towards disallowing the behaviour.

The article's author(s) liked being able to assume that realloc to zero
size would reliably be equivalent to freeing the object pointed to and
setting the pointer to null. This was never a portable assumption, but
their implementation no longer has the option of specifying the
behaviour. This does cause what previously may have been perfectly
reasonable code to now be undefined.

Be well.
--
Lowell Gilbert, embedded/networking software engineer
http://be-well.ilk.org/~lowell/

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

> In article <87zg7n89zw.fsf@bsb.me.uk>,
> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>Lynn McGuire <lynnmcguire5@gmail.com> writes:
>>
>>> On 4/4/2023 6:30 AM, Dan Cross wrote:
>>>> In article <u0fn0g$34scf$1@dont-email.me>,
>>>> 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
>>>>> [snip]
>>>> Yikes. That article is truly awful.
>>>> ACM should be ashamed.
>>>> - Dan C.
>>>
>>> Written by real programmers, not journalists. What do you expect ? Not
>>> everyone is Donald Knuth or Niklaus Wirth.
>>
>>I would expect a more serious tone from an ACM publication, but the
>>journal (ACMQUEUE) is one I don't know and it may well have a more
>>relaxed editorial policy than I am used to. I don't like hyperbole and
>>sarcasm in technical publications but I am not "down with the kids"
>>these days.
>>
>>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.
>>This is not, technically speaking, a bug since I have no reason to
>>suppose the code was intended to be portable across all conforming C
>>implementations, but I'd have pointed it out, had I been a reviewer,
>>since it's an unnecessary distraction to the reader.
>>
>>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. 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.

> Moreoever, there's no
> way to tell whether the underlying object was actually free'd or
> not from the return alone, and checking `errno` is not portable.

Yes.

> The proposal to make realloc with size 0 UB is not bad here:
> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2464.pdf

I did not see any explanation there. What's wrong with leaving it
implementation defined? Is the motivation to tidy up an historical
mess?

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

I did not get that impression. I thought their point was simply that
the code is not undefined and that being implementation defined is safer
than being undefined.

I think the code is poor, and I would not want it in any code base of
mine. It can leak memory (in two different ways) but it does not have
formally undefined behaviour.

> That combined with the little quips about "neurodivergent" ideas
> or about marijuana legalization (really?) smack of proud
> ignorance. That they can't understand at all what `unreachable`
> may be used for makes me think that they may not have as good of
> a handle on the language as they claim.

I didn't like the tone at all, and I was actually rather surprised by
it, given the publisher. But maybe that specific journal is not a very
serious one. I'd never heard of it before today.

> Oh, and among the people championing having `malloc(0)` return a
> non-NULL pointer were Rob Pike and Doug McIlroy. Not that one
> need appeal to authority, but the article's authors would have
> done well to at least, perhaps, listen to some of the viewpoints
> of folks from the lab where C was born before pouring derision
> on ideas that they didn't seem to have a great understanding of.

They didn't discuss that implementation option at all and I agree that
they should have done. But did they pour scorn on it? I only ask
because I don't want to read it again!

--
Ben.

Lowell Gilbert <lgusenet@be-well.ilk.org> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> Lynn McGuire <lynnmcguire5@gmail.com> writes:
>>
>>> On 4/4/2023 6:30 AM, Dan Cross wrote:
>>>> In article <u0fn0g$34scf$1@dont-email.me>,
>>>> 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
>>>>> [snip]
>>>> Yikes. That article is truly awful.
>>>> ACM should be ashamed.
>>>> - Dan C.
>>>
>>> Written by real programmers, not journalists. What do you expect ? Not
>>> everyone is Donald Knuth or Niklaus Wirth.
>>
>> I would expect a more serious tone from an ACM publication, but the
>> journal (ACMQUEUE) is one I don't know and it may well have a more
>> relaxed editorial policy than I am used to. I don't like hyperbole and
>> sarcasm in technical publications but I am not "down with the kids"
>> these days.
>
> Queue is Not An Academic Journal. Because, apparently, working software
> professionals never read academic journals, so it's critical to make
> clear that they aren't one.
>
> Not that they're necessarily all that wrong.

Yes, I see it's described as a magazine.

>> 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.
>
> I think they're saying that before C17, realloc to a size of zero was
> implementation defined, and that C17 changed that to it being
> undefined. That isn't quite right, because it was implementation-defined
> both before and after. But (I think; I don't have a full copy of C17 at
> hand) the limitations were changed, and realloc to a size of zero was
> explicitly described as obsolescent. Unless I'm mistaken factually
> (possible, as I mentioned) I think it's reasonable to consider
> C17 to be moving towards disallowing the behaviour.

I only have a draft of C17. The fact that C standards cost a lot of
money is a valid point. I can't justify paying anything just to be able
to chat on comp.lang.c about some finer points.

The draft I have suggests that C17 just codified what implementation
currently do:

"If the size of the space requested is zero, the behavior is
implementation-defined: either a null pointer is returned to indicate
an error, 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."

and more specifically in realloc:

"If size is zero and memory for the new object is not allocated, it is
implementation-defined whether the old object is deallocated. If the
old object is not deallocated, its value shall be unchanged."

But this may not be the final wording.

> The article's author(s) liked being able to assume that realloc to
> zero size would reliably be equivalent to freeing the object pointed
> to and setting the pointer to null.

.... and returning a null pointer.

> This was never a portable
> assumption, but their implementation no longer has the option of
> specifying the behaviour. This does cause what previously may have
> been perfectly reasonable code to now be undefined.

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.

I was probably being a bit generous. I thought they knew is was not
good code, but that it was, at least, never undefined because care was
taken with the use of the returned pointer and it does not assume that
realloc(ptr, 0) return NULL.

--
Ben.

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.

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.

There was some extended discussion on HN[0].

[0]: https://news.ycombinator.com/item?id=35404025

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 randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/RightWingMedia

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.

One key point is that if the new allocation failed, then the old buffer
was guaranteed to still be allocated and was usable, and this was
indicated by returning a null pointer.

We thus have a conflict in the definition of the API for realloc. If a
zero size parameter means act like free, then realloc has no non-null
value it can return to indicate "success", so needs to return null, but
that means that a null return doesn't mean the input pointer is still valid.

Thus the speciification, and code trying hard to conform to that
specification, needs a lot of words/code to handle the size 0 final case.

Also, this goes back to the idea that malloc could return unique 0-byte
allocations as an implementation option (because some chose to to that
way back when). This is a option that has some uses, but also makes some
code harder to maintain. And for such a system, a call with a 0 size
would return a non-null pointer, so realloc(ptr, 0) wasn't the
equivalent of a free, as it returned a pointer that should eventually be
actually free'd.

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. The authors presented it as a universal property of
all implementations, but it just is not.

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

- Dan C.

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

C99 removes that language, presumably because C89 did not
mandate a particular return value for realloc() in the case
where it behaves like free(), meaning that it is impossible
to tell from the return value alone whether it freed anything
or not. Ben, you already know this, for but others who are
reading along, consider the following:

size_t size = SOMETHING;
char *nptr, *ptr = malloc(size);
// Do something. Error checking elided for brevity.
// Assume that somehow, size is set to zero.
nptr = realloc(ptr, size /* 0 */);
if (nptr == NULL) {
// Now what? Did we fail?
// Or did realloc just,
// if (size == 0) free(ptr);
// return ptr;
// ?
return;
}
// So nptr != NULL.... Ok.
ptr = realloc(nptr, size /* still zero... */);
// Did we just double-free? Or did we malloc()?
// Without also checking size, it's impossible to tell.

>> Moreoever, there's no
>> way to tell whether the underlying object was actually free'd or
>> not from the return alone, and checking `errno` is not portable.
>
>Yes.
>
>> The proposal to make realloc with size 0 UB is not bad here:
>> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2464.pdf
>
>I did not see any explanation there. What's wrong with leaving it
>implementation defined? Is the motivation to tidy up an historical
>mess?

I believe that's correct. The original specification in C89 was
arguably a mistake; the interface, as specified, was almost
impossible to use correctly and, as perverse as I find UB in
general, I feel like the committee made the right decision here.

>> The authors tried to make it out like their code was portable
>> and well-defined. It was not.
>
>I did not get that impression. I thought their point was simply that
>the code is not undefined and that being implementation defined is safer
>than being undefined.
>
>I think the code is poor, and I would not want it in any code base of
>mine. It can leak memory (in two different ways) but it does not have
>formally undefined behaviour.

That is true, but the behavior is implementation-defined and on
some platforms, their code will simply be wrong in the sense of
having a memory leak or worse.

>> That combined with the little quips about "neurodivergent" ideas
>> or about marijuana legalization (really?) smack of proud
>> ignorance. That they can't understand at all what `unreachable`
>> may be used for makes me think that they may not have as good of
>> a handle on the language as they claim.
>
>I didn't like the tone at all, and I was actually rather surprised by
>it, given the publisher. But maybe that specific journal is not a very
>serious one. I'd never heard of it before today.

Queue is meant to be, "for the practitioner." But as the
comment I left on the ACM digital library said, this makes
practitioners look ignorant.

I am very disappointed in ACM here.

>> Oh, and among the people championing having `malloc(0)` return a
>> non-NULL pointer were Rob Pike and Doug McIlroy. Not that one
>> need appeal to authority, but the article's authors would have
>> done well to at least, perhaps, listen to some of the viewpoints
>> of folks from the lab where C was born before pouring derision
>> on ideas that they didn't seem to have a great understanding of.
>
>They didn't discuss that implementation option at all and I agree that
>they should have done. But did they pour scorn on it? I only ask
>because I don't want to read it again!

I would argue that they did, yes. They went on at length about
how it zero-sized objects are an incredibly bad idea, without
giving any consideration to _why_ one might want to use one;
they did the same with `unreachable`.

- Dan C.

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.

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

--
People sleep peaceably in their beds at night only because rough
men stand ready to do violence on their behalf.

George Orwell

On 05/04/2023 11:23, Kenny McCormack 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.

It isn't equivalent to free(). It is implementation-dependent. And
while /some/ implementations handle it like free(), others do not.
Bizarrely, the article authors seem to believe this is guaranteed
behaviour while also giving references to pages showing a range of
different behaviour in real-world C libraries. (And we are not talking
about old, nice or obscure libraries.)

The article is complete nonsense. It is published 3 days early - it
really is a joke. There is very little justification for their
viewpoints in the standards, and very little match between what they say
is in the standards, and what is really there.

Basically, a particular unusual use-case of realloc has changed from
implementation-dependent behaviour (where the implementations vary so
much you can't use it in portable code) to undefined behaviour (which in
real life means different libraries will continue to keep their current
differing behaviours). And the authors write as though this is the end
of the C world as we know it.

/You/ had no idea what happens when realloc'ing with a size of zero.
That's fine - it's not something that makes much sense, and I doubt if
many programmers know what it does. An even smaller proportion will be
correct in what they think they know. If you are writing sensible and
reasonably portable code, there is no change.

(The article also talks a bit about how difficult the standards
sometimes are to understand - that's true enough, but nothing new in C23.)

>
> So, no more...?
>

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.

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.

The Single Unix Specification notes:

"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. If the space
cannot be allocated, the object shall remain unchanged."

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

> Lowell Gilbert <lgusenet@be-well.ilk.org> writes:

[earlier context]

>>>>>> "Catch-23: The New C Standard,Sets the World on Fire"
>>>>>> https://queue.acm.org/detail.cfm?id=3588242
>>>>>> [snip]
>>>>>
>> I think they're saying that before C17, realloc to a size of zero
>> was implementation defined, and that C17 changed that to it being
>> undefined. That isn't quite right, because it was
>> implementation-defined both before and after. But (I think; I
>> don't have a full copy of C17 at hand) the limitations were
>> changed, and realloc to a size of zero was explicitly described as
>> obsolescent. Unless I'm mistaken factually (possible, as I
>> mentioned) I think it's reasonable to consider C17 to be moving
>> towards disallowing the behaviour.
>
> I only have a draft of C17. The fact that C standards cost a lot of
> money is a valid point. I can't justify paying anything just to be
> able to chat on comp.lang.c about some finer points.
>
> The draft I have suggests that C17 just codified what implementation
> currently do: [...]

I think you can find the C17 information you're looking for by
looking at these two documents:

https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2464.pdf
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2438.htm