The GNU C Library version 2.19 is now available(sourceware.org)
sourceware.org
The GNU C Library version 2.19 is now available
https://sourceware.org/ml/libc-alpha/2014-02/msg00224.html
3 comments
What was the patch?
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. 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).
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).
You are not quite correct. Identifiers starting with underscore are reserved only if the second character is an underscore or capital letter. For example, _hello is valid for applications to use, while _Hello and __hello are not.
In ISO C (7.1.3):
All identifiers that begin with an underscore are always reserved for use as identifiers with file scope in both the ordinary and tag name spaces.
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.
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.
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.
- 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.
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.
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.
They were changed to __glibc_unused0 etc not _unused0 to further reduce chance of conflicts.
Yeah thats the one.
[deleted]
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