Bug#522774: possible solutions for __unused problem

[Jonathan Nieder <jrnieder@gmail.com>]

Hi Robert,

Robert Millan wrote:

> When it comes to __attibute__((__unused__)), it's just a matter of
> agreeing on whether to call it __attribute_unused__ or __unused.

I don't agree.  It's perfectly fine for there to be multiple names
for the thing --- the task at hand is dividing up the __* namespace
between libbsd and libc.

Would it be possible to collect a near-exhaustive list of identifiers
like this (i.e., used in BSD application code and starting with __)
that could cause trouble?  Then we can propose sed-ing them away at
header installation time to the libc-ports maintainers (as Thorsten
suggested), and I wouldn't be surprised if such a patch is accepted.

Thanks for moving this forward.  Thoughts below about the alternatives
you mentioned.

Regards,
Jonathan

> - Propose to BSD folks that they accept __attribute_* prefix and
>   define those macros (in addition to __unused etc), then begin
>   accepting patches that replace __unused with __attribute_unused.

If I were in their shoes, I wouldn't be happy about such patches.  It
sounds like heavy patching without much immediate benefit, with no end
in sight (since glibc could start using another keyword the next day).

> - Propose to GCC folks that they define __attribute_* macros in
>   <stddef.h> (they won't define __unused since this would break
>   Linux and Glibc), then bring the same proposal to Clang folks.  If
>   both accept, FreeBSD is much more likely to backport it to GCC 4.2.

Likewise, in their shoes I wouldn't accept such patches.  The macros
are not in the C or POSIX standard and are easy to define in terms of
the __attribute__() feature, so they're not part of what a C compiler
is supposed to do.  Making each implementation of the standard headers
add these macros would hinder portability between implementations
(yes, there are more than two :)).

> - Work with standards bodies (POSIX?) so that they specify either
>   definition (it doesn't matter to us which one, the offending
>   definition will have to adapt).

That sounds like an excellent idea!  Presumably the C working group
would be likely to consider standardizing __attribute__((__unused__))
if it is proposed, since that syntax is already widely implemented.
C++0x has its own attribute syntax which could make something like
[[unused]] possible.