[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Mon, 11 Nov 2013 14:59:12 +0000 (UTC)
From: Thorsten Glaser <tg@...bsd.de>
To: Sam Ravnborg <public-sam-uyr5N9Q2VtJg9hUCZPvPmw@...ne.gmane.org>
cc: Jonathan Nieder
<public-jrnieder-Re5JQEeQqe8AvxtiuMwx3w@...ne.gmane.org>,
Guillem Jover
<public-guillem-+FW4gsLVM0RAfugRpC6u6w@...ne.gmane.org>,
public-linux-kernel-u79uwXL29TY76Z2rM5mHXA@...ne.gmane.org,
public-linux-kbuild-u79uwXL29TY76Z2rM5mHXA@...ne.gmane.org,
public-linux-api-u79uwXL29TY76Z2rM5mHXA@...ne.gmane.org,
Michal Marek <public-mmarek-AlSwsSmVLrQ@...ne.gmane.org>,
Justin Cormack <justin@...cialbusservice.com>
Subject: Re: [PATCH] Use __unused0 instead of __unused for user visible struct
member names
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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists