Assignment between objects of type sigset_t

[Spiros Bousbouras]

int main(void) {
struct sigaction sact , sact_old ;

// Definitions for functions handler() and fatal() not shown ; assume
// they have no issues.

if (sigaction(SIGCHLD , 0 , &sact_old) == -1)
fatal("sigaction() call to get the original signal handling failed") ;
sact.sa_handler = handler ;
sact.sa_flags = 0 ;
sact.sa_mask = sact_old.sa_mask ; // *** Is this OK ? ***
if (sigaction(SIGCHLD , &sact , 0) == -1)
fatal("sigaction(SIGCHLD , ...) failed") ;

...................
}

https://pubs.opengroup.org/onlinepubs/9699919799/functions/sigemptyset.html :
RATIONALE

The implementation of the sigemptyset() (or sigfillset()) function
could quite trivially clear (or set) all the bits in the signal set.
Alternatively, it would be reasonable to initialize part of the
structure, such as a version field, to permit binary-compatibility
between releases where the size of the set varies. For such reasons,
either sigemptyset() or sigfillset() must be called prior to any
other use of the signal set, even if such use is read-only (for
example, as an argument to sigpending()).

If we take this literally then what my code does above is not ok. On the other
hand what I do seems reasonable and the only alternative would be something
like

sigemptyset(&sact.sa_mask) ;
Have variable sig loop over all signals {
if sigismember(&sact_old.sa_mask , sig) sigaddset(&sact.sa_mask , sig) ;
}

If the assignment is not ok then it would be nice if POSIX had something like
sigcopyset(sigset_t *set1 , sigset_t *set2)

GNU offers sigorset(...) but I don't want to use extensions.

--
Somebody was trying to tell me that CDs are better than vinyl because
they don't have any surface noise. I said, "Listen, mate, life has
surface noise."
John Peel

[Spiros Bousbouras]

On Thu, 03 Jun 2021 13:29:07 GMT
Spiros Bousbouras <spi...@gmail.com> wrote:
> int main(void) {
> struct sigaction sact , sact_old ;
>
> // Definitions for functions handler() and fatal() not shown ; assume
> // they have no issues.
>
> if (sigaction(SIGCHLD , 0 , &sact_old) == -1)
> fatal("sigaction() call to get the original signal handling failed") ;
> sact.sa_handler = handler ;
> sact.sa_flags = 0 ;
> sact.sa_mask = sact_old.sa_mask ; // *** Is this OK ? ***
> if (sigaction(SIGCHLD , &sact , 0) == -1)
> fatal("sigaction(SIGCHLD , ...) failed") ;
>
> ...................
> }

I could also do

sigaction(SIGCHLD , 0 , &sact) ;

sact.sa_handler = handler ;
sact.sa_flags = 0 ;

sigaction(SIGCHLD , &sact , 0) ;

and avoid the assignment altogether but this still doesn't fulfill the
requirement "either sigemptyset() or sigfillset() must be called prior to
any other use of the signal set" .In any case , I'm still curious whether
the assignment is ok.

[Rainer Weikusat]

Spiros Bousbouras <spi...@gmail.com> writes:
> int main(void) {
> struct sigaction sact , sact_old ;
>
> // Definitions for functions handler() and fatal() not shown ; assume
> // they have no issues.
>
> if (sigaction(SIGCHLD , 0 , &sact_old) == -1)
> fatal("sigaction() call to get the original signal handling failed") ;

[...]

> sact.sa_mask = sact_old.sa_mask ; // *** Is this OK ? ***

[...]

> https://pubs.opengroup.org/onlinepubs/9699919799/functions/sigemptyset.html :
> RATIONALE
>
> The implementation of the sigemptyset() (or sigfillset()) function
> could quite trivially clear (or set) all the bits in the signal set.
> Alternatively, it would be reasonable to initialize part of the
> structure, such as a version field, to permit binary-compatibility
> between releases where the size of the set varies. For such reasons,
> either sigemptyset() or sigfillset() must be called prior to any
> other use of the signal set, even if such use is read-only (for
> example, as an argument to sigpending()).
>
> If we take this literally then what my code does above is not ok.

Presumably, somebody who's in fan of "undefined behaviour on signed
integer overflow" could construct an argument carefully avoiding to fall
foul of anything that's explicitly mentioned in the text above in order
to make such a claim. But this can be done in any case and is besides the
point, as it ignores the context.

sigemptyset is a function for initializing a sigset_t. Superficially, it
could seem redundant in certain situations because a sigset_t with
storage class "static" will have its memory initialized to all zero
bytes. The rationale just cautions that a sigset_t initialized in this
way isn't necessarily equivalent to "an empty signal set". An even
simpler reason for this could be that "empty" could as well be
represented as "all bits set" as as "all bits clear".

But that's irrlevant for sigset_t assignments. That's a C operation
whose semantics and/or validity depends on the types of the involved
objects.

https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/signal.h.html

demands that sigset_t is an "Integer or structure type", hence, sigset_t
can be used in assignments.

An implementation could sabotage this, but unless specifically
targetting one known to act in this way, I'd ignore the possibility.