Path: csiph.com!news.mixmin.net!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Date: Sat, 08 Apr 2023 18:46:50 -0700 Organization: A noiseless patient Spider Lines: 70 Message-ID: <86v8i54yk5.fsf@linuxsc.com> References: <87zg7n89zw.fsf@bsb.me.uk> <86cz4i5cn1.fsf@linuxsc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: dont-email.me; posting-host="2b6f87d227a563a0c00d2eacd0f30cf4"; logging-data="1658467"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19d7xkPIb7UFX0+xhOg7T2tVRujvK+/+B4=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:ol8YLfUwdypiDzvR47nfQAeT5QA= sha1:qmh7P0fjTSNivA7BUhboz5uAfg8= Xref: csiph.com comp.lang.c:169865 cross@spitfire.i.gajendra.net (Dan Cross) writes: > In article <86cz4i5cn1.fsf@linuxsc.com>, > Tim Rentsch wrote: > >> cross@spitfire.i.gajendra.net (Dan Cross) writes: >> >>> In article <87zg7n89zw.fsf@bsb.me.uk>, >>> Ben Bacarisse 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.