Re: The attribute module

[Bruno Haible]

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