Groups | Search | Server Info | Keyboard shortcuts | Login | Register

Groups > comp.lang.c > #398888

Re: Safety of casting from 'long' to 'int'

Show all headers | View raw

In article <86lddnlvtr.fsf@linuxsc.com>,
Tim Rentsch  <tr.17687@z991.linuxsc.com> 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.

	- Dan C.

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-05 16:22 -0700
  Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-07 01:39 +0000
    Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-06 21:41 -0700
      Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-08 18:26 +0000
        Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-08 15:41 -0700
    Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-06 23:22 -0700
      Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-08 19:06 +0000
        Re: Safety of casting from 'long' to 'int' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-08 13:22 -0700
          Re: Safety of casting from 'long' to 'int' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-08 13:27 -0700
        Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-12 22:31 -0700
          Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-13 15:47 +0000
            Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-13 11:59 -0700
              Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-13 20:45 +0000
              Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-13 15:28 -0700
            Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-13 15:33 -0700
              Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-13 23:56 +0000
    Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-07 10:33 +0200
    Re: Safety of casting from 'long' to 'int' James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-07 18:08 -0400
      Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-08 16:13 +0000
        Re: Safety of casting from 'long' to 'int' scott@slp53.sl.home (Scott Lurndal) - 2026-05-08 16:42 +0000
          Re: Safety of casting from 'long' to 'int' Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-05-08 16:57 +0000
            Re: Safety of casting from 'long' to 'int' James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-08 17:51 -0400
              Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-08 23:03 +0000
        Re: Safety of casting from 'long' to 'int' scott@slp53.sl.home (Scott Lurndal) - 2026-05-08 17:01 +0000
        Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-09 08:37 -0700
          Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-09 22:15 +0000
            Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-09 16:24 -0700

csiph-web