Re:The GNU C Library version 2.19 is now available
by TwoBit on Sunday February 09, 2014 @02:45PM
(#7206814)
I disagree with you. The new code is more practical than the old code, and as standards-conforming as the old code was. There's already a precedent for using numbers after __unused to avoid conflict, and so the new code is more consistent with the old code.
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.
Re:The GNU C Library version 2.19 is now available
by justincormack on Sunday February 09, 2014 @10:41AM
(#7205821)
They were changed to __glibc_unused0 etc not _unused0 to further reduce chance of conflicts.
- 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.