«

-wombat- <> wrote:

> Richard Bos wrote:
> >> "undefined behavior" is a little strong (it's spec-speak for "Programmer!
> >> CYA!")
> >
> > Undefined behaviour is _exactly_ right:
> >
> > # [#5] If the signal occurs other than as the result of
> > # calling the abort or raise function, the behavior is
> > # undefined if ...
> > # ... or the signal
> > # handler calls any function in the standard library other
> > # than the abort function or the signal function with the
> > # first argument equal to the signal number corresponding to
> > # the signal that caused the invocation of the handler.
> >
> > That's from n869, btw. I believe the actual Standard says the same.
>
> It's saying that the standard library makes no gaurantees if anything other
> than raise() or abort() are called.

Exactly. And this is called undefined behaviour in the Standard.

> That's not to say that things don't
> work -- plenty of software out there actually does call standard library
> functions from inside signal handlers, SIGINT being the prime example.

Sure, but those programs assume C _and_ something else, often POSIX.
What POSIX defines in addition, or possibly even contradiction, to the
ISO C Standard is off-topic here, since this is a newsgroup about C, not
about C-for-some-popular-OSes-only.

> >> "unpredictable" is more apropos because the programmer now has to be
> >> careful that whatever the longjmp returns to
> >
> > Once you call longjmp() from a signal handler, it is not even guaranteed
> > _that_ you return anywhere, let alone that it is stable.
>
> Your scenario only makes sense if the signal handler is called with a
> separate stack,

No - my scenario is explicitly allowed by the Standard. Who knows - it
might be a safety feature of the OS. My point is that _unless_ you
assume additional, off-topic, standards you cannot assume that calling
longjmp() from a signal handler does anything at all.

> Besides, if what you said is true, a lot of software would cease to work.

Nonsense. What I say is true, and a lot of software is not written
entirely in ISO C.

Richard

Richard Bos wrote:
>> >> "unpredictable" is more apropos because the programmer now has to be
>> >> careful that whatever the longjmp returns to
>> >
>> > Once you call longjmp() from a signal handler, it is not even
>> > guaranteed _that_ you return anywhere, let alone that it is stable.
>>
>> Your scenario only makes sense if the signal handler is called with a
>> separate stack,
>
> No - my scenario is explicitly allowed by the Standard. Who knows - it
> might be a safety feature of the OS. My point is that _unless_ you
> assume additional, off-topic, standards you cannot assume that calling
> longjmp() from a signal handler does anything at all.
>
>> Besides, if what you said is true, a lot of software would cease to work.
>
> Nonsense. What I say is true, and a lot of software is not written
> entirely in ISO C.

The language has to assume a machine model, without which the language is
utterly useless. The language maps to that hypothetical, perfect virtual
machine. setjmp/longjmp make certain assumptions based on the VM's
structure such that it has validity and will work. One of those VM features
is a stack-based architecture, without which, a lot of C features would be
hard to implement (not impossible, but much harder.)

What you've incorrectly asserted is that "What the standard says must
arbitrarily be true." The standard gives the RTL implementor leeway in the
RTL's implementation such that no gauruntees have to be made in special
situations. No more and no less. Thus, if something doesn't work, the RTL
implementor can point to the standard and assert that they implemented the
standard correctly.

Nothing I said had to do with special OS support structures. I merely
pointed out some of the more common uses of setjmp/longjmp. Moreover, I
pointed how reality (and the VM that maps to the C language) tends to fly
in the face of what the ISO standard would call "undefined" behavior.

But, hey, must be nice to live inside the ISO standard cocoon. Meanwhile,
there's reality for the rest of us.