0

This is an excerpt from SIGACTION(2):

 POSIX.1-1990 specified only SA_NOCLDSTOP. POSIX.1-2001 added SA_NOCLDSTOP, SA_NOCLDWAIT, SA_NODEFER, SA_ONSTACK, SA_RESETHAND, SA_RESTART, and SA_SIGINFO. Use of these latter values in sa_flags may be less portable in applications intended for older UNIX implementations.

And from FEATURE_TEST_MACROS(7):

 _POSIX_C_SOURCE · (Since glibc 2.3.3) The value 200112L or greater additionally exposes definitions corresponding to the POSIX.1-2001 base specification (excluding the XSI extension). This value also causes C95 (since glibc 2.12) and C99 (since glibc 2.10) features to be exposed (in other words, the equivalent of defining _ISOC99_SOURCE).

But in reality, the flags added in 2001 spec is not exposed when the value 200112L is used. So, the following code does not compile. I tried glibc and uclibc.

#define _POSIX_C_SOURCE 200112L #include <string.h> #include <signal.h> #include <unistd.h> static int ret = 1; void handle_signal (const int s) { ret = 0; } int main (const int argc, const char **args) { struct sigaction sa; memset(&sa, 0, sizeof(sa)); sa.sa_flags = SA_RESETHAND; sa.sa_sigaction = handle_signal; sigaction(SIGINT, &sa, NULL); sigaction(SIGTERM, &sa, NULL); pause(); return ret; }

What am I missing here? Are the flags not 2001 base spec? Are they an extension? Or is this just a bug in Linux libc implementations?

Improve this question
8
  • At least on glibc, it seems to be gated by __USE_XOPEN_EXTENDED (so you may need to #define _XOPEN_SOURCE_EXTENDED instead) Commented Oct 6, 2020 at 10:54
  • @schily "Why _POSIX_C_SOURCE=200112L macro define wouldn't expose SA_* flags". Thank you. Commented Oct 6, 2020 at 11:17
  • @Ashethehuman you seem to be suffering from constite. As to your problem, good luck finding a POSIX historian who would confirm you whether SA_RESETHAND has become standard 20 or 15 years ago. In susv3 aka POSIX-1.2001 SA_RESTARTHAND still appears marked as XSI (X/Open System Interface). Assuming that that (googled out) page is right. Commented Oct 6, 2020 at 12:18
  • @user414777 The SA_ macros are from 1990 which is from before SVr4 has been declared final . The definitions at that time have been disabled in Solaris for a strict POSIX or XOPEN compilation. They are IIRC the SYSVr4 equivalent to the BSD sigvec interface. POSIX.1-2001 was the first POSIX standard that adopted the Single UNIX standard and SUSv2 from 1997 definitely included SA_* already. Commented Oct 6, 2020 at 14:26
  • @user414777 Yes, I live in excruciating pain everyday Commented Oct 9, 2020 at 10:58

1 Answer 1

Reset to default
0

In the GNU C library, SA_RESETHAND is exposed by __USE_XOPEN_EXTENDED or __USE_XOPEN2K8. As a result, setting _POSIX_C_SOURCE to 200112 isn’t sufficient; instead, you need

#define _XOPEN_SOURCE 600

(which enables __USE_XOPEN_EXTENDED) or

#define _POSIX_C_SOURCE 200809L

(which enables __USE_XOPEN2K8).

As I understand it, this is POSIX-conformant: before Issue 7, SA_RESETHAND, SA_RESTART, SA_SIGINFO, SA_NOCLDWAIT, and SA_NODEFER were part of the XSI option. They were moved to Base in Issue 7 (2008).

man 2 sigaction comes from the Linux man-pages project, not from the GNU C library, so discrepancies do happen.

Improve this answer
8
  • Well, technically this is the answer to "Why POSIX_C_SOURCE=200112L macro define wouldn't expose SA* flags" Commented Oct 9, 2020 at 10:53
  • It was my mistake that I rephrased the question. What I really wanted to know was if this is a bug in Linux libc implementations. No offence, but I know how to read C code. Commented Oct 9, 2020 at 10:55
  • Sorry, I’ve updated the answer specifically to address whether this is a bug. Commented Oct 9, 2020 at 11:07
  • __USE_XOPEN_EXTENDED is not mentioned in the POSIX standard. As mentioned already, the observed behavior is a result from the odd way of dealing with POSIX on Linux. Commented Oct 10, 2020 at 13:50
  • 1
    @StephenKitt You're right. They were. pubs.opengroup.org/onlinepubs/009695399/basedefs/signal.h.html. They need to update man pages. Commented Oct 11, 2020 at 11:39

You must log in to answer this question.