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

Paul Eggert wrote: > These look good to me too. OK, I pushed them. Bruno -- In memoriam Dora Gerson

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

On 02/13/2011 02:58 PM, Bruno Haible wrote: Objections to these patches? Jim? Paul? These look good to me too. Thanks, Bruno.

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

Bruno Haible wrote: > Paul Eggert wrote: >> > Here's a proposed patch. >> >> That looks good as far as it goes, > > OK, here's a revised patch. Avoids the #ifndef now, and includes some > tests/*.c > files. > >> but while we're at it, >> shouldn't we use a consistent naming convention? >> It's co

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

Paul Eggert wrote: > > Here's a proposed patch. > > That looks good as far as it goes, OK, here's a revised patch. Avoids the #ifndef now, and includes some tests/*.c files. > but while we're at it, > shouldn't we use a consistent naming convention? > It's confusing that one .h file uses _GL_AT

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

Hi Paul, > While that might be useful, there's a downside to it too. > With the current approach, if a program includes two gnulib-supplied > headers (stdin.h and stdlib.h, say), and if these headers due to > some versioning screwup define _GL_ATTRIBUTE_NORETURN differently, > a C compiler is requ

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

On 02/13/2011 03:43 AM, Bruno Haible wrote: > Yes, I agree gnulib should not interfere with the definition of > __attribute__ that the application has provided in its .h files. Or, more generally, gnulib should not suppress the application's use of __attribute__. Emacs did not #define __attribut

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

On 02/13/2011 03:34 AM, Bruno Haible wrote: > it could be useful for applications to override gnulib's > definition of _GL_ATTRIBUTE_NORETURN and _GL_ATTRIBUTE_FORMAT While that might be useful, there's a downside to it too. With the current approach, if a program includes two gnulib-supplied head

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

Paul Eggert wrote: > If this seems OK, we can install similar workarounds for other > misuses of __attribute__ in Gnulib now. Yes, I agree gnulib should not interfere with the definition of __attribute__ that the application has provided in its .h files. Here's a proposed patch. I think the defini

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

> I'm doing the same for stdio.in.h and string.in.h. Actually, it seems it could be useful for applications to override gnulib's definition of _GL_ATTRIBUTE_NORETURN and _GL_ATTRIBUTE_FORMAT. For example in order to include support for other compilers, or for other reasons that I'm not aware of no

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

Hi Paul, > --- a/lib/stdlib.in.h > +++ b/lib/stdlib.in.h > @@ -88,10 +88,10 @@ struct random_data > # include > #endif > > -#ifndef __attribute__ > -# if __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 8) > -# define __attribute__(Spec) /* empty */ > -# endif > +#if 3 <= __GNUC__ || __G

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

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 .

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

Hi Paul, > @@ -119,7 +113,12 @@ struct random_data > /* Terminate the current process with the given return code, without running > the 'atexit' handlers. */ > # if !@HAVE__EXIT@ > -_GL_FUNCDECL_SYS (_Exit, void, (int status) __attribute__ ((__noreturn__))); > +# if @HAVE_ATTRIBUTE_NORETUR