Re: [Q] [A21.5R21.4] Re: [PATCH] gnuserv.h compiler warning
"Stephen J. Turnbull" <stephen(a)xemacs.org> wrote:
QUERY
>>>>> "SY" == Steve Youngs <youngs(a)xemacs.org> writes:
SY> APPROVE 21.5 RECOMMEND 21.4
>> --==> "JJ" == Jerry James <james(a)xemacs.org> writes:
JJ> * gnuserv.h: Include signal.h early to define NSIG before
JJ> config.h is included.
SY> This looks good to me, Jerry. Please commit to 21.5, and
SY> thank you very much for the patch.
I think this is most likely wrong. The Internals manual says to
include config.h before _anything_ else, _including_ system includes.
I won't veto, because I don't know what the right fix is. My guess is
that some fiddling should be done in either config.h itself (probably
requiring some screwing with configure.in, too) or in the s&m files.
I haven't been ignoring this. I just haven't had time to deal with it
until today. I've got more information. First, there is code in
s/usg5-4.h to #include <signal.h> *before* the NSIG test. However, it
is protected by #ifdef emacs ... #endif. When building in src, -Demacs
is passed to the compiler. However, when building in lib-src, -Demacs
is only passed when building digest-doc and make-path. This explains
why I only saw the warning while building in lib-src. However, I don't
understand why -Demacs is passed for just those two lib-src binaries and
no others. Can anybody explain?
Second, see this comment in syssignal.h, just before the #include
<signal.h>:
/* In the old world, one could not #include <signal.h> here. The party line
was that that header should always be #included before <config.h>, because
some configuration files (like s/hpux.h) indicate that SIGIO doesn't work
by #undef-ing SIGIO, and if this file #includes <signal.h>, then that will
re-#define SIGIO and confuse things.
This was, however, a completely fucked up state of affairs, because on some
systems it's necessary for the s/m files to #define things in order to get
<signal.h> to provide the right typedefs, etc. And it's generally a broken
concept for <config.h> to not be the very very first file included.
So instead of #undef'ing SIGIO in the various s/m files, I've changed them
to define BROKEN_SIGIO instead, then we (syssignal.h) do an #undef SIGIO
at the end, after including signal.h. Therefore, it's important that
<signal.h> not be included after "syssignal.h", but that's the
normal state:
nothing should be directly including <signal.h> these days.
-- jwz, 29-nov-93
*/
Third, note that lib-src/gnuserv.h does, in fact, #include <signal.h>.
For that matter, so does lib-src/leditcfns.c, lib-src/tcp.c,
s/cygwin32.h, s/usg5-4.h, getloadavg.c, malloc.c, and unexhp9k3.c.
Also, hftctl.c does a #include <sys/signal.h>.
Fourth, note that syssignal.h contains code for guessing the value of
NSIG if it is not set.
Finally, note that three s&m files contain code to acquire the correct
value of NSIG in various magic ways: m/amdahl.h, s/mingw32.h, and
s/usg5-4.h. However, the one in s/mingw32.h is a simple #define and
probably should not be touched.
So now I suspect that the correct fix is to revert my patch, pull the
NSIG setting code out of m/amdahl.h and s/usg5-4.h and put it into
syssignal.h, delete the #ifdef emacs ... #endif block in s/usg5-4.h, and
change all of the #include <signal.h> instances noted above to #include
"syssignal.h". Does that look correct?
--
Jerry James
http://www.ittc.ku.edu/~james/