Re: ///usr/include/stdlib.h:617: warning: '__malloc__' attribute ignored

[Bruno Haible]

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  <address@hidden>

        * lib/stdlib_.h: Use "#pragma GCC system_header" to suppress some gcc
        warnings.
        Reported by Joel E. Denny <address@hidden> 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@