FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Kernel

 
 
LinkBack Thread Tools
 
Old 06-18-2011, 01:19 PM
Robert Millan
 
Default Bug#522773: possible solutions for __unused problem

It seems there are two traditions for attribute macros.

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-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: BANLkTimJePBuB8gMvXtP4bkMZXd=5FmzvQ@mail.gmail.com ">http://lists.debian.org/BANLkTimJePBuB8gMvXtP4bkMZXd=5FmzvQ@mail.gmail.com
 
Old 06-18-2011, 09:22 PM
Jonathan Nieder
 
Default Bug#522773: possible solutions for __unused problem

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.



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110618212228.GB4096@elie">http://lists.debian.org/20110618212228.GB4096@elie
 
Old 06-18-2011, 09:39 PM
Robert Millan
 
Default Bug#522773: 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



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: BANLkTimipbvr1-k=hN-3zAUPvAWfLSoyfg@mail.gmail.com">http://lists.debian.org/BANLkTimipbvr1-k=hN-3zAUPvAWfLSoyfg@mail.gmail.com
 
Old 06-19-2011, 06:24 PM
Thorsten Glaser
 
Default Bug#522773: possible solutions for __unused problem

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. 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"



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: Pine.BSM.4.64L.1106191822090.20827@herc.mirbsd.org ">http://lists.debian.org/Pine.BSM.4.64L.1106191822090.20827@herc.mirbsd.org
 
Old 06-19-2011, 07:06 PM
Ben Hutchings
 
Default Bug#522773: possible solutions for __unused problem

On Sun, 2011-06-19 at 18:24 +0000, Thorsten Glaser wrote:
> 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
 
Old 06-19-2011, 07:09 PM
Thorsten Glaser
 
Default Bug#522773: possible solutions for __unused problem

Ben Hutchings dixit:

>> 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



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: Pine.BSM.4.64L.1106191908340.20827@herc.mirbsd.org ">http://lists.debian.org/Pine.BSM.4.64L.1106191908340.20827@herc.mirbsd.org
 
Old 07-29-2011, 03:08 PM
Moritz Mühlenhoff
 
Default Bug#522773: possible solutions for __unused problem

On Sun, Jun 19, 2011 at 07:09:37PM +0000, Thorsten Glaser wrote:
> 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



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110729150817.GA23022@pisco.westfalen.local">http ://lists.debian.org/20110729150817.GA23022@pisco.westfalen.local
 
Old 07-29-2011, 04:14 PM
Robert Millan
 
Default Bug#522773: possible solutions for __unused problem

2011/7/29 Moritz Mhlenhoff <jmm@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.

--
Robert Millan



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CAOfDtXMrXy9Tx_5mZdgQoqW-5RvNSjmrtze5qZE5yn3pBERMpQ@mail.gmail.com">http://lists.debian.org/CAOfDtXMrXy9Tx_5mZdgQoqW-5RvNSjmrtze5qZE5yn3pBERMpQ@mail.gmail.com
 

Thread Tools




All times are GMT. The time now is 08:03 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org