Hi Eric,
> > Since it's a utility macro only for the tests, I would much prefer to have
> > it
> > in a file such as tests/macros.h, rather than polluting config.h with stuff
> > that exists only for the tests. This file tests/macros.h could also contain
> > the ubiquitous ASSERT macro. (I try to keep the tests as transparent and
> > will as little boilerplate complexity as possible. But a macro that is used
> > more than 200 times can certainly be refactored.)
>
> OK, then I'll work on making gnulib-tool always distribute tests/macros.h
> along with any test, and move ASSERT into that file (but as separate
> steps, to make the reviews easier).
It does not require a modification of gnulib-tool. tests/macros.h is not
different in principle than tests/nan.h; it's only used in more places.
I'll move the ASSERT macro, and you can then add _GL_CHECK_SIGNATURE (or
whatever you choose to name it) to it.
> > I would leave _UNUSED_PARAMETER_ as it is. It is well named and frequently
> > used. You are now trying to use __attribute__((__unused__)) also for a
> > different case; that does not mean that _UNUSED_PARAMETER_ needs to be
> > changed.
>
> Indeed - that was my original thought when I wrote the following patch
> yesterday. Now pushing:
Oops, you pushed that a bit quickly. I was just saying that _UNUSED_PARAMETER_
is a good name, and there is no reason to rename it. Your new macro _GL_UNUSED
is used in two different syntaxes now: after the identifier (when used for a
function parameter) and before the identifier (in _GL_CHECK_SIGNATURE).
Also, via unistr.h, this macro gains visibility outside of gnulib. Keeping it
defined only in gnulib-common.h leads to bugs in libunistring [1][2], and each
time you rename it, it breaks libunistring. Please don't change unistr.h
without thinking about the implications for libunistring.
Therefore my proposal is to
- create a new module 'unused-parameter', that inserts a definition of
_GL_UNUSED_PARAMETER_ in a header file, like 'link-warning' and
'arg-nonnull'
do,
- update unistr.h accordingly.
This should reduce the dependency between gnulib and libunistring's
infrastructure.
Bruno
[1] http://lists.gnu.org/archive/html/bug-libunistring/2009-12/msg00002.html
[2] http://lists.gnu.org/archive/html/bug-libunistring/2009-12/msg00004.html
