Path: csiph.com!eternal-september.org!feeder.eternal-september.org!nntp.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: Safety of casting from 'long' to 'int' Date: Sat, 09 May 2026 08:37:17 -0700 Organization: A noiseless patient Spider Lines: 63 Message-ID: <86ik8wsifm.fsf@linuxsc.com> References: <10su8cn$am9i$1@dont-email.me> <10tdu47$pms4$3@kst.eternal-september.org> <10tgqgk$rpk$1@reader1.panix.com> <10tj2h0$20gfo$1@dont-email.me> <10tl23g$9o3$1@reader1.panix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Sat, 09 May 2026 15:37:18 +0000 (UTC) Injection-Info: dont-email.me; logging-data="3925730"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+sWnv3Bjnhlz04/dd7CiWWg6P7m7cvJiE="; posting-host="241722c71660d3e26e4790da0fa3960c" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:Papeniw0aU1UuOJLdyr61OedgTQ= sha1:i6B+Uc+wMtlOHtiejNPTGdyfXKA= sha256:UzLXTTEEBTh+DZ9teLHokvWUpYKRlZ+Mw2/WCCWs93k= sha1:eU0mRU7jvbUsFJOAAMLfMduXBcQ= Xref: csiph.com comp.lang.c:398592 cross@spitfire.i.gajendra.net (Dan Cross) writes: > In article <10tj2h0$20gfo$1@dont-email.me>, > James Kuyper wrote: > >> cross@spitfire.i.gajendra.net (Dan Cross) writes: >> ... >> >>> The `realloc` thing was a particularly egregious example of a >>> thing that started life well-defined, then became IB, and then >>> UB; it's relevant because it shows the committee is willing to >>> make weaken the language's guarantees about what is well-defined >>> over time, but I admit that that is rare.When was it ever well-defined? >> >> The C89 standard says: >> "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." >> Prior to C89, the closest thing there was to a standard was K&R, which >> didn't mention realloc() (or most of the rest of what became the C >> standard library). > > In section 7.10.3.4 ("The `realloc` function"), the last > sentence of the "Description" reads: "If `size` is zero and > `ptr` is not a null pointer, the object it points to is freed." > That statement is explicit, and unambiguous. > > The text you quoted is from the prefactory material at the top > of section 7.10.3 ("Memory management functions") and clearly > applies to to `malloc` and `calloc`. > > I suppose one could make an argument to support it applying > to `realloc` as well because it doesn't explicitly *exclude* it, > but that would be a stretch. Not at all. The rule in the C standard is that statements in a higher node of the hierarchy apply to all the child nodes unless a particular child node explicitly alters it. > I counter with two points: a) the > langauge in realloc is more specific, and thus should supercede > the general statement in the earlier introductory text, and b) > the langauge in 7.10.3 is talking about size requested for > allocation, but the language in 7.10.3.4 says that, in the case > it describes, the behavior is to _free_. In that specific case, > no size is "being requested" a la the 7.10.3 language, and thus > the statement about behavior in 7.10.3 does not apply. The two provisions are not in conflict. The semantic description in the realloc() section says the block is free()'d, but doesn't say anything about the return value. The general prelude higher up describes what is returned when the size requested is zero. These two passages are talking about different things, and are not in conflict with each other, and both apply. > The bottom line is that, despite the 7.10.3 wording, C89 > explicitly defined `realloc(ptr, 0);` as equivalent to > `free(ptr)` when `ptr != NULL`. You are simply wrong. There is different wording in C99, and that newer wording is not a change but a clarification of the earlier wording in C89. Such clarifications often occur in the C99 standard.