• Assignment between objects of type sigset_t

    From Spiros Bousbouras@21:1/5 to All on Thu Jun 3 13:29:07 2021
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Rainer Weikusat@21:1/5 to Spiros Bousbouras on Thu Jun 3 16:41:31 2021
    Spiros Bousbouras <spibou@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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)