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: Fri, 08 May 2026 15:33:47 -0700 Organization: A noiseless patient Spider Lines: 37 Message-ID: <868q9ttttg.fsf@linuxsc.com> References: <10su8cn$am9i$1@dont-email.me> <10tbg6g$2ls$2@reader1.panix.com> <86pl3avuqw.fsf@linuxsc.com> <10tdbju$5uj$1@reader1.panix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Fri, 08 May 2026 22:33:48 +0000 (UTC) Injection-Info: dont-email.me; logging-data="3407938"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18caFicxIlk+uN0fw6C0TaxDZThGGvcP8A="; posting-host="12a84863e630bdf33525bc8ffa10a418" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:F8yRrTXbDf64j7ZZMmCGNo9TFjU= sha1:yDixRKR2hsa+1zDLPPYt6lefD3Q= sha256:OO+Fgtktss5WBk+w9tH1bBy44qKSsfdgjc3hV6L6fM4= sha1:lxLSK/7NkCPb2yNl8lYQpNP9M8g= Xref: csiph.com comp.lang.c:398545 cross@spitfire.i.gajendra.net (Dan Cross) writes: > In article <86pl3avuqw.fsf@linuxsc.com>, > Tim Rentsch wrote: > >> cross@spitfire.i.gajendra.net (Dan Cross) writes: >> >>> [...] Or, something _can_ become UB that was not >>> initially; a program who took care to avoid UB in the ANSI C >>> sense might find their program suddenly stops working because a >>> thing they did became UB in a later revision of the standard >>> (e.g., `realloc(0, ...)` becoming UB in C23). >> >> Do you have another example? In my view the change related to >> realloc(0,...) is more a basis for condemning the decisions of >> people on the C23 committee than it is a basis for condemning >> the concept of undefined behavior. > > One that has not already been beaten to death? > > If I sat down and really thought about it, I could probably come > up with something. But I'm not sure that it's worth my time to > do so, or that it would be worth anyone else's time to read what > I come up with. The same arguments are made over and over again > with no one really gaining new understanding, let alone > producing better software as a result. > > [... more along those lines ...] My question is not about whether undefined behavior is good or bad. My question is only if you can point to a construct (other than the realloc() case as noted about) that is defined behavior in one version of the C standard, and is undefined behavior in a later version of the C standard. The question is only about different editions of the C standard; K&R isn't definite enough about defined-versus-undefined behavior to say (and K&R 2 is supposed to be the same as the C89/C90 standard).