Following up on today's bug-bison message
<http://lists.gnu.org/archive/html/bug-bison/2007-02/msg00031.html>.
This seems to be due to the new stdlib module in gnulib. stdlib uses
the new trick of something like this:
#include "///usr/include/stdlib.h"
... gnulib fixups go here ...
But Bison has exposed a problem with this approach. The approach
causes GCC to treat /usr/include/stdlib.h as if it were not a system
include header, which in turn causes GCC to issue diagnostics that it
would not otherwise generate (since GCC is more tolerant of problems
inside system include headers). In this particular case, GCC
complains about the following line in /usr/include/stdlib.h, which is
probably bogus with GCC 4.1.1 (the __malloc__ attribute isn't
documented, so I'm not sure):
extern int posix_memalign (void **__memptr, size_t __alignment, size_t __size)
__THROW __attribute_malloc__;
A simple fix would be for gnulib stdlib.h to include the system
stdlib.h this way:
#if HAVE_INCLUDE_NEXT
# include_next <stdlib.h>
#else
# include "///usr/include/stdlib.h"
#endif
... gnulib fixups go here ...
I worry a bit that this would not work in some non-GCC compilers; they
would complain about the include_next even though they're not
executing it. But perhaps we can cross this bridge when we come
to it (if we ever do).
Another possibility would be to change the Makefile so that it
replaces "#include @ABSOLUTE_STDLIB_H@" with "#include_next
<stdlib.h>" on GCC platforms. This will work with ordinary
compilations, but as I understand it Bruno wants to be able to
generate .h files that can be included by arbitrary compilers.
Another, even trickier possibility, would be to fiddle with #pragma
GCC system_header, but I'd rather avoid that if I can.
Perhaps we should try the HAVE_INCLUDE_NEXT method first. If it
works, we're done. Otherwise we can fall back on the trickier
possibilities.
