4 ms·
Yes, it does. Drepper's two points on the mails are the same points I made above: - your code is not valid C code, fix that. - these changes are pointless, si
by letzjuc 13y ago
Yes, it does. Drepper's two points on the mails are the same points I made above:
- 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.
- justincormack 13y agoThey were changed to __glibc_unused0 etc not _unused0 to further reduce chance of conflicts.
- TwoBit 13y agoI 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.