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: Wed, 13 May 2026 15:33:12 -0700 Organization: A noiseless patient Spider Lines: 91 Message-ID: <86ecjfj5xz.fsf@linuxsc.com> References: <10su8cn$am9i$1@dont-email.me> <10thb36$1prnt$1@kst.eternal-september.org> <10tlc73$qq2$1@reader1.panix.com> <86lddnlvtr.fsf@linuxsc.com> <10u26f0$t9e$1@reader1.panix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Wed, 13 May 2026 22:33:13 +0000 (UTC) Injection-Info: dont-email.me; logging-data="3179643"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18QihOSsAp7q+KdqfSe4prjMCXbRxbTqwM="; posting-host="ace8b6eaa328dcf44f89a3207699c4cb" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:lf8JA6sYOctc8h1cJ1Qr4MCZnS4= sha1:rA8mf4j3zfBx/q8bKd53ENwV7do= sha256:51qwvon0xNxJgCWqjkdFUyQSAGGi7m7WnUW8zXMzFF4= sha1:scb0o5D5Z5a0GJylNl/aVV0qeEM= Xref: csiph.com comp.lang.c:398909 cross@spitfire.i.gajendra.net (Dan Cross) writes: > In article <86lddnlvtr.fsf@linuxsc.com>, > Tim Rentsch wrote: > >> cross@spitfire.i.gajendra.net (Dan Cross) writes: >> >> [...] >> >>> It is not clear to me that `longjmp` out of a non-nested signal >>> handler is still well-defined as of C11, though it is explicitly >>> stated to be C89. >> >> It seems you are misunderstanding what the standards are saying. > > You read my post with insufficient care, and failed to > understand what I wrote, and are responding to something I did > not say. > >> The description of longjmp() says (paraphrasing) that it restores >> the environment where the relevant setjmp() was done. > > Yes. > >> There is >> in C89 a passage about returning from signal handlers and so >> forth, but that is followed by a carveout for nested signal >> handlers, which in C89 is undefined behavior. (I assume that >> also holds for C90 but I haven't verified that.) > > Yes. > > Aside: surely it is well well-known by now that the language in > C90 is verbatim identical to the language for C89 except for > some bits of the front matter that explain the provenance of the > standard originating from ANSI. > > If you know of specific differences, or a reason this is known > to be incorrect, please point it out. > >> Starting in C99, any mention of interrupts and signal handlers was >> removed, along with the carveout. > > This is wrong. Section 7.14 of C23 talks about signals and > signal handlers at length. > > I never mentioned "interrupts" at all (traditionally, Unix > signals, which formed the basis for C signals, are not > interrputs in the conventional sense. Modern systems will > sometimes make use of interprocessor-interrupts to hasten their > delivery, however). > > I think you are talking about _only_ the description of > `longjmp`. I am actually talking about the standard considered > in total. I only mentioned "non-nested" signal handler because > C90 was explicit in saying that that `longjmp` from a _nested_ > signal handler was UB. > >> Because there is a definition >> for what longjmp() does, the behavior is defined, and there is no >> undefined behavior (not counting things like doing a longjmp() >> with a jmp_buf that wasn't set up, etc). Removing the mention of >> interrupts and signals, and also removing the carveout, only makes >> longjmp() more defined, not less. > > I don't think you understood my statement. > > Read section 7.14 of C23 carefully; it is not at all obvious > that a `longjmp` out of a signal handler is not _a priori_ UB. > By my reading, it's the opposite, in fact: I see no way to do > so without invoking UB. > > I was asked for an example, beyond the behavior of > `realloc(ptr, 0)` with respect to whether it free's `ptr` if > `ptr` is non-null, where something that was explicitly > guaranteed by an earlier version of the standard was changed to > UB in a later version. This appears another example of such a > case. > > By all means, correct me if you think I am mistaken, but your > explanation above was based on your own misinterpretation, not > otherwise relevant to the statement I had made, and incorrect > in fact (the standard did _not_ remove mention of signals). > > Note, in the case of `longjmp` and signal handlers, I suspect it > doesn't much matter because if one is doing something like that > anyway, as one is almost invariably going to targeting a system > that conforms to a standard like POSIX, which extends ISO C with > stronger guarantees for defined behavior in this specific area. I replied to Keith Thompson's reply downthread.