The GNU C Library version 2.19 is now available • Hacker News Board

Re: The GNU C Library version 2.19 is now available

#11

Post by justincormack » Sun, Feb 09, 2014, 3:00 PM UTC

letzjuc wrote: post #8

rquirk wrote: post #5

Earlier quoted context omitted.

Maybe this one? http://sourceware.org/ml/libc-alpha/2013-10/msg00870.html and Drepper's original response in 2012 - https://sourceware.org/ml/libc-alpha/2012-01/msg00039.html "Ehm, no. All symbols starting with _ belong to the system. I'm not going to make any change to enable broken software. Just fix that broken code."

Well, I'm sorry to disagree with you but Drepper is right. In C and C++ identifiers starting with an underscore are reserved for the implementation. Standard library implementors deal with extremely ugly code full of underscores everywhere to avoid this sort of problems. 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. S…

The implementation doesn't have to be an asshole. The policy is now that glibc will use the subset __glibc_. The problem is where there are multiple contexts of what is "the" implementation. In my case it was cross compiling NetBSD. Just because it is pedantically correct behaviour does not mean it cannot be changed to pedantically correct beahviour whats nicer for everyone.

Re: The GNU C Library version 2.19 is now available

#12

Post by letzjuc » Sun, Feb 09, 2014, 3:25 PM UTC

justincormack wrote: post #11

letzjuc wrote: post #8

Earlier quoted context omitted.

Well, I'm sorry to disagree with you but Drepper is right. In C and C++ identifiers starting with an underscore are reserved for the implementation. Standard library implementors deal with extremely ugly code full of underscores everywhere to avoid this sort of problems. 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. S…

The implementation doesn't have to be an asshole. The policy is now that glibc will use the subset __glibc_. The problem is where there are multiple contexts of what is "the" implementation. In my case it was cross compiling NetBSD. Just because it is pedantically correct behaviour does not mean it cannot be changed to pedantically correct beahviour whats nicer for everyone.

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.

Re: The GNU C Library version 2.19 is now available

#13

Post by justincormack » Sun, Feb 09, 2014, 3:41 PM UTC

letzjuc wrote: post #12

justincormack wrote: post #11

Earlier quoted context omitted.

The implementation doesn't have to be an asshole. The policy is now that glibc will use the subset __glibc_. The problem is where there are multiple contexts of what is "the" implementation. In my case it was cross compiling NetBSD. Just because it is pedantically correct behaviour does not mean it cannot be changed to pedantically correct beahviour whats nicer for everyone.

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 wh…

They were changed to __glibc_unused0 etc not _unused0 to further reduce chance of conflicts.

Re: The GNU C Library version 2.19 is now available

#14

Post by TwoBit » Sun, Feb 09, 2014, 7:45 PM UTC

letzjuc wrote: post #12

justincormack wrote: post #11

Earlier quoted context omitted.

The implementation doesn't have to be an asshole. The policy is now that glibc will use the subset __glibc_. The problem is where there are multiple contexts of what is "the" implementation. In my case it was cross compiling NetBSD. Just because it is pedantically correct behaviour does not mean it cannot be changed to pedantically correct beahviour whats nicer for everyone.

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 wh…

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.