Bug#522774: possible solutions for __unused problem
2011/6/18 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
Providing multiple names is fine, the problem is which ones to use.
If BSD developers agree to provide both __attribute_unused and
__unused, and switch their users to __attribute_unused, problem is
solved.
If Drepper agrees to provide __unused, problem would be solved
but this won't happen.
> 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?
Yes, just read the GNU and BSD versions of <sys/cdefs.h>...
> 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.
... but I don't think this will fly.
>> - 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).
I can see they wouldn't be excited about it, but they might also accept
them. This is not a recurrent problem: it's irrelevant if glibc changes it
to another keyword (heck, there isn't even any equivalent to __unused
RIGHT NOW), what matters is that we'd have found a way out the name
collision.
>> - 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 :)).
Actually, I realized afer writing this that the point of these macros
is precisely
portability among different compilers. Moving them to a GCC header is
out of the question (we might as well just use
__attribute__((__unused__)) then).
>> - 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.
Well I have no experience working with standards bodies (and no spare
time), but if someone wants to take it, I'm almost certain this would
resolve our problem.
--
Robert Millan
Reply to: