Two questions to consider:
- What other effects would it have to define '_POSIX' ? In which other places
is this macro being referenced?
It is used to define modes for read/write in fcntl.h (O_RDONLY and friends), getlogin and possibly alarm in io.h, fileno, tempnam and some other functions and constants in stdio.h, rand_r in stdlib.h, sigset_t in sys/types.h, tzset and some related functions in time.h, to define ftruncate and friends in unistd.h with off32_t rather than _off32_t, __USE_MINGW_ANSI_STDIO if not already defined in _mingw.h, and the off_t types without a leading underscore in _mingw_off_t.h.
It would be possible to ensure that _POSIX is defined, #include signal.h, then undefine _POSIX if it was not previously defined, and this would avoid switching on POSIX functionality in other headers by accident.
- Is it useful to have these signal names defined at all? If they can never
occur on native Windows, it does not necessarily make sense to define them.
If I wanted native (non-POSIX) functionality, I would not have used the signal-h module.
Also consider the workarounds that Gnulib already does, in
doc/posix-headers/signal.texi .
I'm already using this, of course! It defines SIGPIPE (but not other missing signals).
signal.texi claims that sigset_t will be defined on Windows, but it does this just by #including <sys/types.h>, which does not define sigset_t unless _POSIX is defined.
The only mention I can find of _POSIX in gnulib is in doc/posix-functions/getlogin.texi, which mentions that getlogin is only defined on mingw if _POSIX is defined (as I noted above). The solution of the getlogin module is to use the unistd module to declare getlogin, if I understand correctly.