Re: OT: Windows (Was: Re: Open Source does not mean easily

In article <vlh4mo$1nccc$1@dont-email.me>,
James Kuyper  <jameskuyper@alumni.caltech.edu> wrote:

On 1/6/25 11:46, Scott Lurndal wrote:

Muttley@DastardlyHQ.org writes:

...

Unix signals should only be used to set flags that are then read later.

 
You're opinion is not widely shared.   Note that the POSIX specification
carefully notes which interfaces are not signal-safe.

>
What precisely does "signal-safe" mean? As I understand it, it is
supposed to be safe for a signal to interrupt standard library routines,
but that it's not safe for a signal handler to call most of those
functions. There's just a few exceptions, described below.

From POSIX 2024, sectino 2.4 ("Signal Concepts"):

|The following table defines a set of functions and
|function-like macros that shall be async-signal-safe.
|Therefore, applications can call them, without restriction,
|from signal-catching functions.  Note that, although there is
|no restriction on the calls themselves, for certain functions
|there are restrictions on subsequent behavior after the
|function is called from a signal-catching function (see longjmp()).
(https://pubs.opengroup.org/onlinepubs/9799919799/functions/V2_chap02.html#tag_16_04)

(The table mentioned above includes over 200 functions.)

The C standard says the following about signal handlers:
"The functions in the standard library are not guaranteed to be
reentrant and may modify objects with static or thread storage duration.
239)" (7.1.4p4)
Footnote 239 says "Thus, a signal handler cannot, in general, call
standard library functions."

This is comp.unix.programmer, not comp.lang.c.

[snip]
>
"If a signal occurs other than as the result of calling the abort or
raise functions, the behavior is undefined if the signal handler reads
or modifies an atomic object that has an indeterminate representation."
(7.17.2p2)
>
"If a signal occurs other than as the result of calling the abort or
raise functions, the behavior is undefined if the signal handler calls
the atomic_init generic function." (7.17.2.1p4)
>
The POSIX standard claims that its version of <signal.h> conforms to the
C standard, and as far as I can see, the POSIX standard doesn't say
anything to define the behavior that is undefined by the C standard.

This is factually incorrect.

Could you demonstrate how, within the above restrictions, a signal
handler that doesn't cause the program to exit in one fashion or another
could do anything useful other than "set flags that are read later"?

Those restrictions don't apply in this context.  But a trivial
example:

    void
    reaper(int signo)
    {
        (void)signo;
        wait(NULL);
    }


    /* ... */
    signal(SIGCHLD, reaper);

I'm not saying it cannot be done. I claim no expertise in this kind of
programming - I never needed to write signal handlers.

Perhaps read up on the matter before commenting, then?

However, the last
time I considered the matter carefully (which was two or three versions
of the C standard ago) I couldn't figure out how to do much more than
that. At that time I did not consider how POSIX affects the issue, and I
don't know enough about POSIX signals to evaluate that issue.

In strict C, this is correct.  But while POSIX includes ISO C as
a subset, it extends allowable behavior in lots of places to
both standardize the behavior of existing programs as well as
make it possible to write useful programs on Unix-style systems.

- Dan C.