[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-api
Subject:    Re: [PATCH] Use __unused0 instead of __unused for user visible struct member names
From:       Thorsten Glaser <tg () mirbsd ! de>
Date:       2013-11-11 14:59:12
Message-ID: Pine.BSM.4.64L.1311111448490.23723 () herc ! mirbsd ! org
[Download RAW message or body]




Sam Ravnborg dixit:

>> Guillem Jover wrote:

>> > On BSD systems __unused has traditionally been defined to mean the
>> > equivalent of gcc's __attribute__((__unused__)), some parts of the
[…]
>^__ is reserved for libc internal stuff and there is no reason to
>name the unused/padding members "__unused".

Considering that glibc has seen the light ¹ now too, can we please
do something about these now? The BSD tools (not just NetBSD ®) have
been using this for far longer after all…


Currently (git pull --ff torvalds master), we have:

• 2 occurrences of files *inside* the Linux kernel defining __unused
  to ² __attribute__((unused)) themselves

• 68 struct members and function arguments called __unused

>So one or a set of patches that rename them all to something more
>sensible would be fine.

I think __unused0 is okay as it matches current __unused[0-9] in
use by other parts of the Linux kernel – although glibc now uses
__glibc_reserved[0-9], I think this doesn't look like the Linux
kernel should use it ☻☺


â‘  http://thread.gmane.org/gmane.comp.lib.glibc.alpha/36439

â‘¡ I've recently come to the belief that this should be
  __attribute__((__unused__)) in all cases, i.e. all those
  attribute namings need double underscores before and after,
  as some software likes to #define printf to something else,
  lighttpd does #define bounded something else, so there's
  probably software out there containing #define unused foo.


--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]