Bug 14186

Summary: linux-libc-dev: uses "__unused" as identifier, which is traditionally used by BSD as macro
Product: Other Reporter: Thorsten Glaser (t.glaser)
Component: OtherAssignee: other_other
Status: CLOSED WILL_NOT_FIX    
Severity: normal CC: alan
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 2.6.29 Subsystem:
Regression: No Bisected commit-id:

Description Thorsten Glaser 2009-09-17 10:03:08 UTC
The BSD API has been offering the following thing in <sys/cdefs.h> for years:

#define __unused __attribute__((unused))

(Of course, if that attribute is not supported – old gcc, non-gcc compiler,
it expands to nothing.)

Userspace applications and libraries use it for when they implement
functions where the API (e.g. callbacks) mandates arguments that are
not ever used/needed by the functions.

Now, post Debian Lenny, my port of MirBSD make (which comes with a few
support utilities and a library) stopped compiling because both the
Linux kernel headers and the GNU glibc userspace headers started using
“__unused” as a structure element, ignoring existing practice.

In contrast to other things, where renaming is possible, or cpp tricks,
there is no simple solution, because the macro has to be visible at the
time the (system) headers are included already.

Please refrain from using “__unused” (using “__unused_” or something like
that is okay) as a courtesy to people porting BSD tools to the GNU/Linux
ecosystem.

A very “simple” way of working around this is, if your sed(1) supports
the word boundary markers used, to pipe the headers through the following
command: sed -e 's/[[:<:]]__unused[[:>:]]/&_/g'

If anyone reading this has good connections to the GNU glibc maintainers,
I would be thankful if this were brought up with him as well.

Thanks in advance!

PS: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=522773 is this bug too,
for the kernel headers; 522774 for glibc. The eglibc people refused the
aforementioned sed fix, despite having to patch “only” the Makefile actually
installing them, for fear of large diffs relative to upstream.
Comment 1 Thorsten Glaser 2012-06-14 08:10:34 UTC
You know, closing this really reflects poorly on Linux’ wish to interoperate.
Especially now that there’s hope to get the glibc side fixed, with the new
management they have.
Comment 2 Alan 2012-06-14 09:28:27 UTC
You filed it in 2009, nobody cares so I closed it.

If you want to change that then send patches. That is how Linux works.