Bug#522774: possible solutions for __unused problem
Robert Millan
The GNU one produced things like:
#define __attribute_malloc__ __attribute__ ((__malloc__))
#define __attribute_pure__ __attribute__ ((__pure__))
#define __attribute_used__ __attribute__ ((__used__))
#define __attribute_noinline__ __attribute__ ((__noinline__))
#define __always_inline __inline __attribute__ ((__always_inline__))
The BSD one produced things like:
#define __malloc_like __attribute__((__malloc__))
#define __pure __attribute__((__pure__))
#define __used __attribute__((__used__))
#define __noinline __attribute__ ((__noinline__))
#define __always_inline __attribute__((__always_inline__))
When it comes to __attibute__((__unused__)), it's just a matter of
agreeing on whether to call it __attribute_unused__ or __unused.
The problem is that there's severe NIH to overcome. As you can
see with the bug you submitted to Linux developers, they're generally
very hostile to portability. The same applies to Glibc (aka Drepper).
Here are some possible ways out of this I can think of:
- 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.
- 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.
- 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).
What I would definitely NOT do is waste any time trying to persuade
Drepper to remove __unused from Glibc or Linux developers to remove
__unused from Linux.
--
Robert Millan
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Jonathan Nieder
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.
Robert Millan
> 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
Thorsten Glaser
>I can see they wouldn't be excited about it, but they might also accept
You know that there are more than one BSD, but only one glibc,
IIRC Drepper isn’t even its maintainer any more. Try persuading
for example Theo de Raadt of anything which doesn’t have any
immediate technical merit… have fun ;-)
Honestly, when resolving this I’d go for “who has the older
rights”. Maybe look at how CSUR resolves different claims to
the same part of the Unicode PUA, or something like that.
Nevertheless, thanks on picking this up.
bye,
//mirabilos
--
Sometimes they [people] care too much: pretty printers [and syntax highligh-
ting, d.A.] mechanically produce pretty output that accentuates irrelevant
detail in the program, which is as sensible as putting all the prepositions
in English text in bold font. -- Rob Pike in "Notes on Programming in C"
Ben Hutchings
> Robert Millan dixit:
>
> >I can see they wouldn't be excited about it, but they might also accept
>
> You know that there are more than one BSD, but only one glibc,
> IIRC Drepper isn’t even its maintainer any more.
According to <http://www.gnu.org/software/libc/> "Ulrich Drepper is
currently the foremost contributor and has overall responsibility for
maintenance and development."
> Try persuading
> for example Theo de Raadt of anything which doesn’t have any
> immediate technical merit… have fun ;-)
>
> Honestly, when resolving this I’d go for “who has the older
> rights”. Maybe look at how CSUR resolves different claims to
> the same part of the Unicode PUA, or something like that.
> Nevertheless, thanks on picking this up.
Debian GNU/Linux is the older system; the Debian GNU/kFreeBSD
maintainers have to deal with compatibility issues.
Ben.
--
Ben Hutchings
Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer
Thorsten Glaser
>> Honestly, when resolving this I’d go for “who has the older
>> rights”. Maybe look at how CSUR resolves different claims to
>> the same part of the Unicode PUA, or something like that.
>> Nevertheless, thanks on picking this up.
>
>Debian GNU/Linux is the older system; the Debian GNU/kFreeBSD
>maintainers have to deal with compatibility issues.
The use of __undefined in the BSDs predates use of it by
both Linux and GNU. (But when using this argumentation
style, we’d probably better take this upstream… except
that upstream may not be helping…)
bye,
//mirabilos
--
“It is inappropriate to require that a time represented as
seconds since the Epoch precisely represent the number of
seconds between the referenced time and the Epoch.”
-- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2
Moritz Mühlenhoff
> Ben Hutchings dixit:
>
> The use of __undefined in the BSDs predates use of it by
> both Linux and GNU. (But when using this argumentation
> style, we’d probably better take this upstream… except
> that upstream may not be helping…)
We already asked you back in September 2009 to report this upstream.
If you don't think that will help, we can just close the bug, then.
Cheers,
Moritz
Robert Millan
> We already asked you back in September 2009 to report this upstream.
He did, precisely in September 2009:
https://bugzilla.kernel.org/show_bug.cgi?id=14186
He still got no response though.
--
Robert Millan
Salvatore Bonaccorso
On Fri, Jul 29, 2011 at 06:14:18PM +0200, Robert Millan wrote:
> 2011/7/29 Moritz Mühlenhoff <j...@inutil.org>:
> > We already asked you back in September 2009 to report this upstream.
>
> He did, precisely in September 2009:
>
> https://bugzilla.kernel.org/show_bug.cgi?id=14186
>
> He still got no response though.
posted patch I guess we can close this bug. Not doing so yet though.
Regards,
Salvatore
Diederik de Haas
was closed (in a less then courteous way).
I just checked 'arch/alpha/include/uapi/asm/stat.h' in Linus' master branch
and the patch proposed by Ben, more then 6 years ago, hasn't been merged.
As I don't know the reason it wasn't closed last year, I won't do it, but
maybe it's time to finally close it?
Thorsten Glaser
>and the patch proposed by Ben, more then 6 years ago, hasn't been merged.
>
>As I don't know the reason it wasn't closed last year, I won't do it, but
>maybe it's time to finally close it?
Prod them occasionally.
I know that *some* __unused have been fixed; maybe the remaining
ones were an oversight?
bye,
//mirabilos
--
[...] if maybe ext3fs wasn't a better pick, or jfs, or maybe reiserfs, oh but
what about xfs, and if only i had waited until reiser4 was ready... in the be-
ginning, there was ffs, and in the middle, there was ffs, and at the end, there
was still ffs, and the sys admins knew it was good. :) -- Ted Unangst über *fs