On 15/07/11 08:50, Paul Eggert wrote: > On 07/14/11 17:25, Pádraig Brady wrote: >> I'm not sure about defining these to 0 in gnulib. >> That will silently ignore the intent of a program on certain platforms. >> Wouldn't it be better to fail to compile so that each program then does: >> >> #ifndef SA_RESETHAND >> /* do something else */ >> #endif > > Well, as a matter of style, I prefer this: > > if (! SA_RESETHAND) > do_something_else (); > > as that's much more likely to detect bitrot in the "do something else" > part.
Absolutely. What I was getting was that it's probably better to leave the following to the app too: #ifndef SA_RESETHAND # define SA_RESETHAND 0 /* Now the app writer knows they need to handle this case */ #endif Otherwise new users of sigaction() or whatever may not be aware of portability issues. They're all documented, but they're too easy to miss there IMHO. > (Of course this is all assuming the application writer knows > about platforms where SA_RESETHAND isn't implemented.) > > On NonStop, if you invoke signal(), it uses the SA_RESETHAND semantics > (POSIX allows this). Conversely, if you invoke sigaction(), NonStop > always behaves as if SA_RESTART and SA_RESETHAND are zero, i.e., it > doesn't support either feature with sigaction. Thanks for checking that. > I just now checked coreutils. Two programs use SA_RESETHAND. The > first (csplit) is clearly using it incorrectly, and won't work > properly on any host that implements SA_RESETHAND according to POSIX. agreed > The second (dd) is using the above idiom already, that is, it is > assuming SA_RESETHAND is #defined to 0 on hosts that don't support it. > (It has some obsolete comments though, that need fixing.) > Conversely, the two programs that depend on SA_RESTART will > probably misbehave if a signal interrupts a system call on > NonStop. I see no easy fix for this, and I expect the gnulib > change may be the best we can do. Again, that gnulib change would only paper over the issue. cheers, Pádraig.