[RFC][patch] cygwin/singal.h is not compatible with -std=c89 or -std=c99

Václav Haisman V.Haisman@sh.cvut.cz
Sat Nov 25 15:47:00 GMT 2006

I've tried to compile following test case with -std=c99 and later with
-std=c89 flags and it fails to compile.

#include <signal.h>

sigchld_handler (int s)
{ }

main (void)
  struct sigaction sa;

  sa.sa_handler = sigchld_handler;

The problem is that the declaration of struct sigaction uses GCC extension
that is turned off by the -std=c99 or -std=c89 flag. The declaration looks
like this. (I stripped the comment that was there to make the line shorter.):

struct sigaction
    _sig_func_ptr sa_handler;
    void  (*sa_sigaction) ( int, siginfo_t *, void * );
  sigset_t sa_mask;
  int sa_flags;

Notice the anonymous unnamed union. This extension is used few more times in
other parts of the same header. I can see two approaches to fixing this.

1. Use GCC's __extension__ keyword before the union (which the attached patch
2. or use a little bit of macro magic like FreeBSD's sys/signal.h header does.

The first approach uses another GCC extension to cover up use a GCC
extension. Pros are that it does not uglify the code much and the change is
very localized. Also the use of this __extension__ on architecture that
probably will never use anything but GCC does not seem that bad. Cons are
that it can be done in without the extension.

The second approach uses C89 and C99 conforming code but it makes the code a
little bit ugly. The following is what FreeBSD does:

struct sigaction {
        union {
                void    (*__sa_handler)(int);
                void    (*__sa_sigaction)(int, struct __siginfo *, void *);
        } __sigaction_u;                /* signal handler */
        int     sa_flags;               /* see signal options below */
        sigset_t sa_mask;               /* signal mask to apply */

#define sa_handler      __sigaction_u.__sa_handler

So, the attached patch is the minimal patch I used locally to compile my
programme. I think the header (and probably other headers) should be fixed
(either way) to allow to be compiled with stricter C standard conformance
flags like the two mentioned. The question is which way does Cygwin want to
go, use extensions in headers or do without them?

Vaclav Haisman
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: signal.h.diff
URL: <http://cygwin.com/pipermail/cygwin-patches/attachments/20061125/0d583e4d/attachment.ksh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 542 bytes
Desc: OpenPGP digital signature
URL: <http://cygwin.com/pipermail/cygwin-patches/attachments/20061125/0d583e4d/attachment.sig>

More information about the Cygwin-patches mailing list