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:51:09 -0700 Organization: A noiseless patient Spider Lines: 128 Message-ID: <86zf29seg2.fsf@linuxsc.com> References: <10su8cn$am9i$1@dont-email.me> <10te56b$rpfu$1@dont-email.me> <10tfclh$7vb$1@reader1.panix.com> <10tflij$19d6u$1@dont-email.me> <10tg55j$kvp$1@reader1.panix.com> <10tgfs8$1i2g4$1@dont-email.me> <10thqam$1vfmr$1@kst.eternal-september.org> <10thu77$1v1r3$2@dont-email.me> <10ti57c$2234d$1@dont-email.me> <10ti6um$233oc$2@dont-email.me> <10tj66r$2f84d$1@kst.eternal-september.org> <10tke55$2pui2$2@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Fri, 08 May 2026 22:51:12 +0000 (UTC) Injection-Info: dont-email.me; logging-data="3407938"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+KFlpFB4EbSbiKD8hnaxBBdg1gx0bGb5s="; posting-host="12a84863e630bdf33525bc8ffa10a418" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:I5fmhbQL4CT0+l2KXDd8KhvOYmI= sha1:wGVKh7RvZE4tXlOtJTt4h6ZiFHY= sha256:gn4Fw/wVOEb+h0vNuGuOx7fIHc7BllElmCOkN42o3cg= sha1:3tZPnlqJz+E6ckFO9eYuymYgg30= Xref: csiph.com comp.lang.c:398549 Bart writes: > On 08/05/2026 00:11, Keith Thompson wrote: > >> Bart writes: >> >>> On 07/05/2026 14:48, David Brown wrote: >>> >>>> On 07/05/2026 13:48, Bart wrote: >> >> [...] >> >>>>> Meanwhile I will probably add '-fwrapv' to 'fno-strict-aliasing' >>>>> in my script for compiling generated C when using gcc**. >>>> >>>> It has taken a long, /long/ time to get you to understand that this >>>> is appropriate for they way you want to work. >>> >>> So, how would you describe overflow behaviour with that option in >>> place: UB, implementation defined, erroneous, unspecified, or other? >>> >>> If not UB, then does it still come under the 'UB' umbrella, or am I >>> using a new dialect where this particular UB doesn't exist? >>> >>> What happens when someone runs my program without the options >>> stipulated? If it goes wrong, who's fault is that? >> >> This is a fairly long response, and there isn't any new information >> in it. Readers won't miss much by skipping it. >> >> You've asked several questions. I'm going to answer them. I'm going >> to pretend for the moment that you actually care about the answers. >> I might tell you some things you don't currently know, and I'm >> going to pretend that this might be a learning experience for you. >> >> I don't recall ever seeing you react positively to someone here >> giving an accurate answer to a question you've asked. I don't think >> I've ever seen you learn something and indicate that you benefited >> from it. I've often seen you express anger and contempt about >> accurate information that people have given you. You're asking >> now about undefined behavior, implementation-defined behavior, and >> unspecified behavior, but you've explicitly said that you refuse >> to read the C standard's definitions of those terms, so I can't >> imagine how my answer is going to be useful to you. I'm not going >> to say anything that I haven't said here before, but someone might >> learn something from it or find it interesting. >> >> Premise: You have a program that contains an instance of signed >> integer overflow, which is undefined behavior in standard C. >> You compile the program with a compiler-specific option that's >> documented to guarantee 2's-complement wraparound semantics for >> signed integer overflow. >> >> Concretely, let's say it's this program: >> >> #include >> #include >> int main(void) { >> int n = INT_MAX; >> n ++; >> printf("%d\n", n); >> } >> >> It's still "undefined behavior" as that technical term is defined >> by the C standard. No compiler option can change the wording >> of the C standard. If you read that definition, I believe you >> could easily understand why that's the case. The technical term >> "undefined behavior" does not mean just "behavior that is not >> defined by anything". Since you don't care, I won't explain yet >> again what it does mean. >> >> An implementation that defines for itself the behavior of signed >> overflow could be fully conforming. It is not a violation of >> the standard to behave in some particular way in the presence of >> undefined behavior -- something you could have figured out if you >> read the standard's definition. >> >> If someone compiles and runs the program without the options you >> refer to, it's still "undefined behavior" as that term is defined >> by the standard. What the code will actually do depends on the >> implementation (no, that doesn't mean it's "implementation-defined") >> and on other factors. It's entirely possible that it will behave >> the same way as if the option weren't used. (As it happens, that's >> the behavior I saw just now on my system.) >> >> You ask whose fault it is if it "goes wrong". > > The question I'm asking really is whether such a program is valid C, > considered in isolation from whatever means is used to translate and > execute it. > > The latter may employ '-ftrapv' to ensure predictable behaviour. > > Or whether a program has to be coupled with a specific implentation > and a set of options before the question can be satisfied. > > > The actual scenerio I had in mind was: > > * There exists a program in another language > * That language expects signed overflow to work like unsigned overflow > * It is transpiled to C code > * Signed overflow may or may not occur in the execution, and it may or > may not be due to a bug in the original program > > So, is that general C file, before it is translated and executed, > valid C? > > If it is compiled with '-fwrapv', can it be assumed to not have UB if > overflow were to occur? > > If it were compiled without '-fwrapv', can it be assumed that UB > occurs if such overflow happens? > > But since signed overflow may or may not occur (it depends on runtime > inputs), I assume you can't tell from the static C code whether the > program is invalid or not (this is not about actual bugs). > > In short, if UB was to happen in the running C program, is the only > thing that's wrong, and needs changing, is that '-fwrapv' flag? Is your goal to solve a problem, or to offer a complaint about C? If your goal is to solve a problem, it should be easy enough to produce code that works around the potential undefined behavior, since you are generating the C code that gets compiled. See for example my recent posting with the two functions safely_add() and safely_multiply().