Paul Eggert wrote:
> 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__;
Yes. This declaration is bogus with the current gccs, since the return type
is not a pointer type. This was fixed in glibc on 2005-07-15, but glibcs
older than this are still much in use.
> 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.
Thanks for both suggestions. They both work. For a gcc specific problem,
I think it's ok to use a gcc specific workaround. Since the gcc doc
says the following about #include_next:
The use of `#include_next' can lead to great confusion. We
recommend it be used only when there is no other alternative. In
particular, it should not be used in the headers belonging to a specific
program; it should be used only to make global corrections along the
lines of `fixincludes'.
but there's no obvious drawback of the #pragma approach, I'm applying this:
2007-02-19 Bruno Haible <[EMAIL PROTECTED]>
* lib/stdlib_.h: Use "#pragma GCC system_header" to suppress some gcc
warnings.
Reported by Joel E. Denny <[EMAIL PROTECTED]> via Paul Eggert.
*** lib/stdlib_.h 19 Feb 2007 00:08:40 -0000 1.3
--- lib/stdlib_.h 19 Feb 2007 22:51:33 -0000 1.4
***************
*** 18,29 ****
--- 18,45 ----
#if defined __need_malloc_and_calloc
/* Special invocation convention inside glibc header files. */
+
+ /* This #pragma avoids a warning with "gcc -Wall" on some glibc systems
+ on which <stdlib.h> has an inappropriate declaration, see
+ <http://sourceware.org/bugzilla/show_bug.cgi?id=1079>. */
+ #ifdef __GNUC__
+ # pragma GCC system_header
+ #endif
+
#include @ABSOLUTE_STDLIB_H@
+
#else
/* Normal invocation convention. */
#ifndef _GL_STDLIB_H
#define _GL_STDLIB_H
+ /* This #pragma avoids a warning with "gcc -Wall" on some glibc systems
+ on which <stdlib.h> has an inappropriate declaration, see
+ <http://sourceware.org/bugzilla/show_bug.cgi?id=1079>. */
+ #ifdef __GNUC__
+ # pragma GCC system_header
+ #endif
+
#include @ABSOLUTE_STDLIB_H@
