Bug #6283

using struct sigaction under -std=c99 seemingly needs -D__EXTENSIONS__

Added by Richard PALO about 4 years ago. Updated about 4 years ago.

Start date:
Due date:
% Done:


Estimated time:


non c99 is fine, but with -std=c99 I need to add -D__EXTENSIONS__ to compile
a module using struct sigaction.... no mention of this need in the manpages.

richard@omnis:/home/richard/src/tsigaction$ cat tsigaction.c
#include <signal.h>

struct sigaction sa;
richard@omnis:/home/richard/src/tsigaction$ /opt/gcc-4.8.1/bin/gcc -Wall  -c tsigaction.c 
richard@omnis:/home/richard/src/tsigaction$ /opt/gcc-4.8.1/bin/gcc -Wall -std=c99  -c tsigaction.c 
tsigaction.c:3:18: error: storage size of ‘sa’ isn’t known
 struct sigaction sa;
richard@omnis:/home/richard/src/tsigaction$ /opt/gcc-4.8.1/bin/gcc -Wall -std=c99 -D__EXTENSIONS__ -c tsigaction.c 

seems to have been like this a long time, but is it correct?



Updated by Robert Mustacchi about 4 years ago

There's a big difference between the two gcc invocations, which is subtle. In the first case you're implicitly using -std=gnu89, where as in the second, you're using -std=c99. When gcc is used with an explicit C standard it then emits the __STRICT_ANSI__ pre-processor macro which is used to trigger strict ISO C compliance mode. Unfortunately gcc doesn't provide a way to both not have GNU C extensions to the language and not have a restrictive environment. Because gcc has declared that you want strict ANSI compliance, unless you use a SUS related standards macro, you'll be confined to what's defined in ISO C99 generally (which does not include signals).

If you compile it with -std=c89, it will also fail. Where as, if you compile it with -std=gnu99, it'll succeed.


Updated by Richard PALO about 4 years ago

Yes, I understand the difference between the commands.

My issue is :
1. The manpage does not mention the need for EXTENSIONS
2. Other systems, for example NetBSD, do not seem to need any extensions
to compile successfully.

So my point is, why are extensions necessary in SunOS? And why for reasons undocumented?
this last link talks about the contents of struct sigaction.

[CX] [Option Start] The header shall provide a declaration of struct sigaction, including at least the following members:

void (*sa_handler)(int)  Pointer to a signal-catching function or one of the macros 
                         SIG_IGN or SIG_DFL. 
sigset_t sa_mask         Set of signals to be blocked during execution of the signal 
                         handling function. 
int      sa_flags        Special flags. 
void (*sa_sigaction)(int, siginfo_t *, void *)
                         Pointer to a signal-catching function. 

It only has the footnote:
[CX][Option Start] Extension to the ISO C standard [Option End]
The functionality described is an extension to the ISO C standard. Application writers may make use of an extension as it is supported on all IEEE Std 1003.1-2001-conforming systems.

With each function or header from the ISO C standard, a statement to the effect that ``any conflict is unintentional'' is included. That is intended to refer to a direct conflict. IEEE Std 1003.1-2001 acts in part as a profile of the ISO C standard, and it may choose to further constrain behaviors allowed to vary by the ISO C standard. Such limitations are not considered conflicts.

Where additional semantics apply to a function or header, the material is identified by use of the CX margin legend.

See help on Margin Code Notation.


Updated by Richard PALO about 4 years ago

I noticed, by chance, the following from boost/config/posix_features:

      // POSIX version 3 requires <signal.h> to have sigaction:
#     if defined(_POSIX_VERSION) && (_POSIX_VERSION >= 199506L)
#        define BOOST_HAS_SIGACTION
#     endif

in /usr/include/sys/unistd.h illumos defines:

350 #ifndef _POSIX_VERSION
351 #ifdef  _XPG6
352 #define _POSIX_VERSION          200112L /* Supports IEEE Std 1003.1-2001 */
353 #else
354 #define _POSIX_VERSION          199506L /* Supports POSIX-1c DIS */
355 #endif
356 #endif /* _POSIX_VERSION */

so perhaps the conditions for struct sigaction should be looked at again.

Also available in: Atom PDF