2011/6/18 Jonathan Nieder <jrnie...@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-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
