Groups | Search | Server Info | Login | Register

Groups > comp.lang.c > #398909

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

Show all headers | View raw

cross@spitfire.i.gajendra.net (Dan Cross) writes:

> 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.

I replied to Keith Thompson's reply downthread.

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

Thread

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