Accepting that patch is sending the wrong message. First, it would say that if your project is big/important enough, you can do whatever you want. Second, it would say that they are willing to fix these issues, which I think is even worse.
So IMO, he took the right decision for every project using libc, which is to reject your patch, and to tell you to fix your code.
If you decide to write non-standard conforming code, then you deserve what you get (probably ABI breakage).
In ISO C++ (17.4.3.2.1): Each name that begins with an underscore is reserved to the implementation for use as a name in the global namespace.
In both (7.1.3 / 17.4.3.2.1): Each name that contains a double underscore (_ _) or begins with an underscore followed by an uppercase letter (2.11) is reserved to the implementation for any use.
The rule of thumb is never give a name that start with an underscore (simple, right?).
That goes for C and C++. In C++ people think that they are a bit safer because of namespaces, but I've seen it create problems when someone writes an using directive in a header file (dont do this). It will work on their project but break yours. And finding which header is causing this is a nightmare in small-medium sized projects. In big projects it deserves to get someone fired.
Note: if you really want/need to break this rule, choose a name that will not conflict with anything! E.g. in Boost file guards have a randomly generated character sequence appended at their end. They are not doing anything "illegal", but is a policy they have just to be sure.
- your code is not valid C code, fix that.
- these changes are pointless, since _unused0 could create problems in another system using invalid C code.
So unless there is a very good reason why this cannot be fixed upstream (and it has too be much better than "sorry but we are used to write invalid C code"), then I sincerely don't see why this patch should be accepted.
> The problem is where there are multiple contexts of what is "the" implementation.
The fact that the macro _unused doesn't conflict with NetBSD's implementation of libc doesn't mean that you should use it if you want portability. Sooner or later you are going to get this problem with a different libc implementation. You could submit a patch to that implementation to "fix" it, but you would be again avoiding the true problem, which is that the _unused macro is invalid C.
However, I agree that a patch proposing a more properly portable name would be better and should be encouraged. If Drepper were a little less hostile than his usual self, he would have been more amenable to a good cooperative solution like the __glibc_ solution.
Assholes will ruin your project[1], you need to get rid of them, whether it is open source or not.
[1] http://www.youtube.com/watch?v=-ZSli7QW4rg