Hi Akim,
> Bison started to use the new attribute module, but it generates conflicts
> with other modules, because one definition comes from config.h, and another
> from the other module's file. For instance:
>
> > In file included from ../lib/bitsetv.c:21:
> > In file included from ../lib/bitsetv.h:24:
> > In file included from ../lib/bitset.h:31:
> > In file included from ../lib/bitset/base.h:28:
> > ../lib/xalloc.h:43:10: warning: '_GL_ATTRIBUTE_ALLOC_SIZE' macro redefined
> > [-Wmacro-redefined]
> > # define _GL_ATTRIBUTE_ALLOC_SIZE(args)
> > ^
> > ./lib/config.h:1657:10: note: previous definition is here
> > # define _GL_ATTRIBUTE_ALLOC_SIZE(args) __attribute__ ((__alloc_size__
> > args))
> > ^
>
> I can provide a patch to address this, but I don't know what's the guideline
> here.
The guideline is:
* The _GL_ATTRIBUTE_* macros are defined in m4/gnulib-common.m4, from where
the definitions are propagated into config.h.
- In application code, you MAY use these macros, at your own risk - since
they are not documented so far.
- In the lib/*.in.h header files, that may (in some circumstances) be used
without a preceding '#include <config.h>' and that therefore are designed
to be as standalone as possible, you can use the _GL_ATTRIBUTE_* macros
if you have added a fallback definition.
- In all the rest of gnulib, you can use these macros directly and
unconditionally.
* The ATTRIBUTE_* macros are defined through attribute.h, but rely on
m4/gnulib-common.m4.
- In application code, this is the preferred API.
- In the lib/*.in.h header files, you should not use these macros, not
even with a fallback definition, since symbols that don't start with _GL_
could too easily collide with application code's symbols.
- In all the rest of gnulib, you can use these macros, after having added
'#include "attribute.h"' and a module dependency towards 'attribute'.
Also, I avoid to use _GL_ATTRIBUTE_FORMAT and ATTRIBUTE_FORMAT, because of a
tricky override of 'printf' by '__printf__', done in gnulib and libintl.
Also, in code shared with glibc, e.g. the regex module, we haven't started
to use either. Recall that there are periodic manual sync-ups between glibc
and gnulib.
> Also, what's the rule inside gnulib to decide whether to use _GL_ATTRIBUTE_FOO
> rather than using attribute.h and ATTRIBUTE_FOO?
In most of gnulib, e.g. the 'bitset' module, it's a matter of taste, I'd say.
Bruno
