Bruno Haible <[EMAIL PROTECTED]> 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.
