Re: async-signal-safe functions

[Jim Meyering]

Bruno Haible <address@hidden> wrote:

> Eric Blake wrote:
>> +         /* POSIX states that sigprocmask and signal are both
>> +            async-signal-safe.
>
> Going through the list of async-signal-safe functions, gnulib overrides
> quite a few. I propose to add comments so that this is remembered in future
> modifications of the functions.
>
> OK to apply the attached comments, Jim?

I would prefer it if the repeated 4-line blocks were all exactly
identical, along with a rule to ensure they stay that way, but I
won't require that.  It feels slightly backwards to be adding
so much duplication-with-variants (albeit comment-only), when we
typically normalize or factor out duplication.

> There are problems with the mkdir(), rmdir(), rename() substitutes.
> The rmdir() substitute could be removed; it is most probably not needed any
> more nowadays. For mkdir() and rename(), a workaround would be to assume a
> file name of length PATH_MAX at most. But this would be a pessimization of
> the current code (for the normal case that the function is called from the
> main program, not from a signal handler).

I suspect that rmdir.c hasn't been used for several years, and
the comments in mkdir.c and rename.c suggest they work around
bugs in systems that are no longer reasonable portability targets,
so unless they're relevant to less-ancient systems, I wouldn't
spend time on them.

Similarly, getgroups targets systems (Ultrix 4.3 and NextStep 3.2) that
are quite old.  It's no coincidence that each of these functions calls
an exit-on-failure allocator like xmalloc (vestiges of when they were
in coreutils).  Not at all appropriate for library code, but they're
not used anymore, so it's ok.

> Is there a portable way to detect whether the program is currently executing
> a signal handler?

I don't know off hand.
Finding such old systems (in order to run portability tests)
may be a challenge.