Subject: Re: bug#9076: coreutils-8.12 uses SA_RESETHAND and SA_RESTART unconditionally

From: Pádraig Brady <[email-masked]>
Date: Fri, 15 Jul 2011 11:28:33 +0100

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.