Bug 275328 - <signal.h> fails to expose SA_* macros without XSI
Summary: <signal.h> fails to expose SA_* macros without XSI
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: standards (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Only Me
Assignee: Warner Losh
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-11-25 10:35 UTC by Jan Beich
Modified: 2023-12-05 04:15 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Beich freebsd_committer freebsd_triage 2023-11-25 10:35:34 UTC
According to POSIX.1-2008:

> Issue 7
[...]
> The SA_RESETHAND, SA_RESTART, SA_SIGINFO, SA_NOCLDWAIT, and SA_NODEFER constants are moved from the XSI option to the Base.

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

which doesn't seem to work on FreeBSD:

$ cc a.c
a.c:6:39: error: use of undeclared identifier 'SA_RESTART'
    6 |   struct sigaction sa = { .sa_flags = SA_RESTART, /* .sa_handler = myfunc */ };
      |                                       ^
1 error generated.

#define _POSIX_C_SOURCE 200809L
#include <signal.h>

int main()
{
  struct sigaction sa = { .sa_flags = SA_RESTART, /* .sa_handler = myfunc */ };
}
Comment 1 Warner Losh freebsd_committer freebsd_triage 2023-11-25 16:41:49 UTC
diff --git a/sys/sys/signal.h b/sys/sys/signal.h
index 0ab2a205a92c..8f3a0dec8fee 100644
--- a/sys/sys/signal.h
+++ b/sys/sys/signal.h
@@ -391,7 +391,7 @@ struct sigaction {
 #define        SA_NOCLDSTOP    0x0008  /* do not generate SIGCHLD on child stop */
 #endif /* __POSIX_VISIBLE || __XSI_VISIBLE */

-#if __XSI_VISIBLE
+#if __XSI_VISIBLE || __POSIX_VISIBLE >= 200809
 #define        SA_ONSTACK      0x0001  /* take signal on signal stack */
 #define        SA_RESTART      0x0002  /* restart system call on signal return */
 #define        SA_RESETHAND    0x0004  /* reset to SIG_DFL when taking signal */

Appears to be the ask. It seems reasonable. I'll note that there's a number of alignment issues with the standards that we have (usually erring on the side of defining too much). A large part of the reason for this is that while POSIX.1-2008 (aka Issue 7) and (to a lessor degree) POSIX.1-2001 (issue 6) are basically available, earlier versions are not, so it is kinda hard to retrospectively get all the fiddly details right. other implementations also are sloppy in this regard towards earlier standards, leading to the mistaken impression that symbols are available earlier than they really are (note: note the case here, this bug is spot on).

Unless I see an objection soonish, I'll commit and merge this in the coming weeks.

Is there a specific port for this that prompted this test/bug?
Comment 2 Jan Beich freebsd_committer freebsd_triage 2023-11-25 18:34:21 UTC
(In reply to Warner Losh from comment #1)
> Is there a specific port for this that prompted this test/bug?

See the inline comment referencing this bug in ports f03dfb7a662f. Upstream added _POSIX_C_SOURCE in v0.4 but SA_RESTART appeared in v0.5. Neither _GNU_SOURCE nor _DEFAULT_SOURCE are defined, so this may not be upstream fault.
Comment 3 Jan Beich freebsd_committer freebsd_triage 2023-12-05 04:15:21 UTC
Ditto ports 254231223bab.