[10528] in Athena Bugs
decmips 7.4H: /usr/include/signal.h
daemon@ATHENA.MIT.EDU (Calvin Clark)
Wed Jun 2 13:12:28 1993
Date: Wed, 2 Jun 93 13:12:23 -0400
From: Calvin Clark <ckclark@MIT.EDU>
To: bugs@Athena.MIT.EDU
System name: hodge
Type and version: KN01 7.4H
Display type: PMAX-MFB
What were you trying to do?
Build gcc.
What's wrong:
Versions of gcc later than 2.4 massage header files to get them to be
more ANSI-compliant. One of the things that is done is to take anything
like this:
#ifdef foo
...
#endif foo
and convert it to this:
#ifdef foo
...
#endif /* foo */
This is almost always a safe operation. Unless, of course, you are
dealing with ULTRIX. Consider the following excerpt from <signal.h>:
/*
* Information pushed on stack when a signal is delivered.
* This is used by the kernel to restore state following
* execution of the signal handler. It is also made available
* to the handler to allow it to properly restore state if
* a non-standard exit is performed.
*
#ifdef __vax
* XXX - sigcontext needs updating per 4.3BSD - rr
*
#endif __vax
#ifdef __mips
* WARNING: THE sigcontext MUST BE KEPT CONSISTENT WITH /usr/include/setjmp.h
* AND THE LIBC ROUTINES setjmp() AND longjmp()
#endif __mips
*/
The gcc fixincludes algorithm will make a broken header file out of this
by creating nested comments. I am not saying that this header file is
non-compliant. Strictly speaking, there is nothing technically wrong
with it. Any utter gibberish between /* and */ is allowed. But it's
really gross and should be made nicer. At least take the bad C out of
the comment, so gcc won't break it. (And it is bad C: section 3.8 of
the ANSI spec states ``thou shall not have turds between #else or #endif
and the end of the line.'' Well, in so many words.)
What should have happened:
Someone should have gone through the header files and fixed up things
marked with ``XXX.'' You laugh; there's quite a few of them.
Please describe any relevant documentation references:
ANSI X3.159-1989, section 3.8
