Bug#522774: possible solutions for __unused problem

[Robert Millan <rmh@debian.org>]

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