# sigemptyset

## PROLOG



           This manual page is part of the POSIX Programmer's Manual.  The
           Linux implementation of this interface may differ (consult the
           corresponding Linux manual page for details of Linux behavior), or
           the interface may not be implemented on Linux.
    


## NAME



           sigemptyset — initialize and empty a signal set
    


## SYNOPSIS



           #include <signal.h>
    
           int sigemptyset(sigset_t *_set_);
    


## DESCRIPTION



           The _sigemptyset_() function initializes the signal set pointed to
           by _set_ , such that all signals defined in POSIX.1‐2008 are
           excluded.
    


## RETURN VALUE



           Upon successful completion, _sigemptyset_() shall return 0;
           otherwise, it shall return -1 and set _errno_ to indicate the error.
    


## ERRORS



           No errors are defined.
    
           _The following sections are informative._
    


## EXAMPLES



           None.
    


## APPLICATION USAGE



           None.
    


## 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_()).  This
           function is not intended for dynamic allocation.
    
           The _sigfillset_() and _sigemptyset_() functions require that the
           resulting signal set include (or exclude) all the signals defined
           in this volume of POSIX.1‐2017. Although it is outside the scope
           of this volume of POSIX.1‐2017 to place this requirement on
           signals that are implemented as extensions, it is recommended that
           implementation-defined signals also be affected by these
           functions. However, there may be a good reason for a particular
           signal not to be affected. For example, blocking or ignoring an
           implementation-defined signal may have undesirable side-effects,
           whereas the default action for that signal is harmless. In such a
           case, it would be preferable for such a signal to be excluded from
           the signal set returned by _sigfillset_().
    
           In early proposals there was no distinction between invalid and
           unsupported signals (the names of optional signals that were not
           supported by an implementation were not defined by that
           implementation). The **[EINVAL]** error was thus specified as a
           required error for invalid signals. With that distinction, it is
           not necessary to require implementations of these functions to
           determine whether an optional signal is actually supported, as
           that could have a significant performance impact for little value.
           The error could have been required for invalid signals and
           optional for unsupported signals, but this seemed unnecessarily
           complex. Thus, the error is optional in both cases.
    


## FUTURE DIRECTIONS



           None.
    


* * *