>I agree; stuff simply should NOT be including <sys/signal.h>.  It's been
>that way for a long time.

Absoutely qtrue. but the dodgy code exists.  silently miscompiling it,
so code that works on other platforms fails is ... not robust engineering.

If we do that, then dodgy code that ``works properly everywhere else
-- FreeBSD, OpenBSD, LInux, ...''  silently blows up on NetBSd.  Even
if what we do is strictly right, that doesnt look good.



>#if !defined(_KERNEL) && !defined(_SIGNAL_H_)
>#error You must include <signal.h> for signal function prototypes.
>#endif

Jason, in your own inimitable style: ``BZZZT!''

sys/param.h includes sys/signal.h.  (which is how perl got into this
mess in the first place.)  If we do that, then including <sys/param.h>
without first including <signal.h> will break.

Wrapping the declarations of sigset_t and struct sigaction with
	#if defined(_KERNEL) || defined(_SIGNAL_H_)

would almost work -- it forces the user to #include <signal.h> to get
the struct definition -- but only if it was done outside of
    #ifndef _SYS_SIGNAL_H_.

so that a second include, after <signal.h>, makes
sigset_t/struct sigaction visible.

Or we could ensure move the RENAMEd decls and the structs into a
header file of their own (so we never get one visible withot the
other), but with the userland decls inside #ifndef _KERNEL.

sys/signal.h would do
#ifdef _KERNEL
    #include <new-file-with-structs-and-renames>
    #endif

and signal.h can pull in the new file regardless.  (or we could just
put it all in sys/signal.h, except that makes the dodgy code work,
rather than giving a compile-time warning.)


>No, when we bump the major number, all of the renames go away...

Amen to that.