1SIGEMPTYSET(3P) POSIX Programmer's Manual SIGEMPTYSET(3P)
2
6 This manual page is part of the POSIX Programmer's Manual. The Linux
7 implementation of this interface may differ (consult the corresponding
8 Linux manual page for details of Linux behavior), or the interface may
9 not be implemented on Linux.
10
12 sigemptyset — initialize and empty a signal set
13
15 #include <signal.h>
16 int sigemptyset(sigset_t *set);
18
20 The sigemptyset() function initializes the signal set pointed to by
21 set, such that all signals defined in POSIX.1‐2008 are excluded.
22
24 Upon successful completion, sigemptyset() shall return 0; otherwise, it
25 shall return -1 and set errno to indicate the error.
26
28 No errors are defined.
29 The following sections are informative.
31
33 None.
34
36 None.
37
39 The implementation of the sigemptyset() (or sigfillset()) function
40 could quite trivially clear (or set) all the bits in the signal set.
41 Alternatively, it would be reasonable to initialize part of the struc‐
42 ture, such as a version field, to permit binary-compatibility between
43 releases where the size of the set varies. For such reasons, either
44 sigemptyset() or sigfillset() must be called prior to any other use of
45 the signal set, even if such use is read-only (for example, as an argu‐
46 ment to sigpending()). This function is not intended for dynamic allo‐
47 cation.
48 The sigfillset() and sigemptyset() functions require that the resulting
50 signal set include (or exclude) all the signals defined in this volume
51 of POSIX.1‐2017. Although it is outside the scope of this volume of
52 POSIX.1‐2017 to place this requirement on signals that are implemented
53 as extensions, it is recommended that implementation-defined signals
54 also be affected by these functions. However, there may be a good rea‐
55 son for a particular signal not to be affected. For example, blocking
56 or ignoring an implementation-defined signal may have undesirable side-
57 effects, whereas the default action for that signal is harmless. In
58 such a case, it would be preferable for such a signal to be excluded
59 from the signal set returned by sigfillset().
60 In early proposals there was no distinction between invalid and unsup‐
62 ported signals (the names of optional signals that were not supported
63 by an implementation were not defined by that implementation). The
64 [EINVAL] error was thus specified as a required error for invalid sig‐
65 nals. With that distinction, it is not necessary to require implementa‐
66 tions of these functions to determine whether an optional signal is
67 actually supported, as that could have a significant performance impact
68 for little value. The error could have been required for invalid sig‐
69 nals and optional for unsupported signals, but this seemed unnecessar‐
70 ily complex. Thus, the error is optional in both cases.
71
73 None.
74
76 Section 2.4, Signal Concepts, pthread_sigmask(), sigaction(),
77 sigaddset(), sigdelset(), sigfillset(), sigismember(), sigpending(),
78 sigsuspend()
79 The Base Definitions volume of POSIX.1‐2017, <signal.h>
81
83 Portions of this text are reprinted and reproduced in electronic form
84 from IEEE Std 1003.1-2017, Standard for Information Technology -- Por‐
85 table Operating System Interface (POSIX), The Open Group Base Specifi‐
86 cations Issue 7, 2018 Edition, Copyright (C) 2018 by the Institute of
87 Electrical and Electronics Engineers, Inc and The Open Group. In the
88 event of any discrepancy between this version and the original IEEE and
89 The Open Group Standard, the original IEEE and The Open Group Standard
90 is the referee document. The original Standard can be obtained online
91 at http://www.opengroup.org/unix/online.html .
92 Any typographical or formatting errors that appear in this page are
94 most likely to have been introduced during the conversion of the source
95 files to man page format. To report such errors, see https://www.ker‐
96 nel.org/doc/man-pages/reporting_bugs.html .
97IEEE/The Open Group 2017 SIGEMPTYSET(3P)