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: Tue, 11 Apr 2023 04:05:19 -0700 Organization: A noiseless patient Spider Lines: 36 Message-ID: <86a5ze4r2o.fsf@linuxsc.com> References: <87bkk26sx1.fsf@bsb.me.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: dont-email.me; posting-host="b8523dcffbf3f55a5b42bbad23f83ee0"; logging-data="2740034"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+4GjTMIEzw5MSNXxpeBap9Z8osABvknMY=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:7yDUj0Qp0aQJhJNXf9LthHa0AcA= sha1:2yxwPcQfa4Wp2Uj3asBt4wtfVzA= Xref: csiph.com comp.lang.c:169968 Ben Bacarisse writes: > cross@spitfire.i.gajendra.net (Dan Cross) writes: [..concerning whether realloc() with a size of 0 must free()..] >> The authors presented it as a universal property of >> all implementations, but it just is not. > > I don't think they do. Right. > 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) I believe the authors mean to refer to statements in the two C Rationale documents (and indeed it is the case that these documents discuss matters concerning how memory management behave). > 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 me it seems clear that the authors mean to distinguish between what behaviors are /recommended/ (or at least that they think are recommended) and what behaviors are /described or specified/ by the various C standards over the years (which definitely have changed in different official releases of the C standard). And it seems obvious that the authors recognize that these two things are not the same.