Re: [PATCH] stdlib: support non-GCC __attribute__

[Paul Eggert]

On 02/12/2011 05:11 PM, Bruno Haible wrote:
> This patch substitutes compiler dependent values into the generated stdlib.h.
> This goes against our efforts to make these generated .h files as compiler
> independent as possible, so that packages can install private copies of the
> gnulib generated .h files (like libunistring does for stdbool.h and stdint.h,
> and Simon's packages do this as well).

These efforts are problematic, since they're getting in the way of the
typical use of gnulib to supply workarounds for deficient platforms.

For now, we can work around the problem (see patch below), but there
must be a better way.  How about if we add an option to gnulib-tool
to address this?  I.e., gnulib-tool could generate a stdin.in.h
designed for the typical use of gnulib, or it could generate a
stdin.in.h suitable for libunistring etc.  The typical use could
employ Autoconf tests to accurately determine the current compiler's
behavior; the private-copy use could work much as now, and generate
less-accurate but still-acceptable results.

In this particular case it's OK if __attribute__((__noreturn__)) is
omitted; all that means is that the code will be
slightly slower.  In the future, though, it may well be more
important to have accurate uses of __attribute__ (as the example
of alignment with Emacs showed).  If so, the private-copy use
will have to figure out how to sidestep the issue, possibly at
further loss of efficiency.

I installed this patch, which is good enough for Emacs for now.
It uses __attribute__ ((__noreturn__)) only for GCC, so it
means that non-GCC compilers will generate slightly-slower
code or worse warnings.  This is a bit of a problem, but
it's OK for now.  I don't want to get into the business of
maintaining by hand a list, for each compiler, which
attributes it supports, and which version it started supporting
each attribute in, but for now it's OK to do this with GCC only
since we've sort of been doing it anyway.

If this seems OK, we can install similar workarounds for other
misuses of __attribute__ in Gnulib now.  I still would like that
gnulib-tool option, though.

2011-02-12  Paul Eggert  <address@hidden>

        stdlib: don't get in the way of non-GCC __attribute__
        See thread starting at
        <http://lists.gnu.org/archive/html/bug-gnulib/2011-02/msg00161.html>.
        Revert previous stdlib change, installing the following instead:
        * lib/stdin.in.h (__attribute__): Remove.  We do not want
        to get in the way of a non-GCC compiler that supports __attribute__.
        (_GL_ATTRIBUTE_RETURN): New macro.
        (_Exit): Use it instead of __attribute__.

diff --git a/lib/stdlib.in.h b/lib/stdlib.in.h
index 6e69a27..62d18c6 100644
--- a/lib/stdlib.in.h
+++ b/lib/stdlib.in.h
@@ -88,10 +88,10 @@ struct random_data
 # include <unistd.h>
 #endif
 
-#ifndef __attribute__
-# if __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 8)
-#  define __attribute__(Spec)   /* empty */
-# endif
+#if 3 <= __GNUC__ || __GNUC__ == 2 && 8 <= __GNUC_MINOR__
+# define _GL_ATTRIBUTE_NORETURN __attribute__ ((__noreturn__))
+#else
+# define _GL_ATTRIBUTE_NORETURN
 #endif
 
 /* The definitions of _GL_FUNCDECL_RPL etc. are copied here.  */
@@ -119,7 +119,7 @@ struct random_data
 /* Terminate the current process with the given return code, without running
    the 'atexit' handlers.  */
 # if address@hidden@
-_GL_FUNCDECL_SYS (_Exit, void, (int status) __attribute__ ((__noreturn__)));
+_GL_FUNCDECL_SYS (_Exit, void, (int status) _GL_ATTRIBUTE_NORETURN);
 # endif
 _GL_CXXALIAS_SYS (_Exit, void, (int status));
 _GL_CXXALIASWARN (_Exit);