The GNU C Library version 2.19 is now available
sourceware.org
The GNU C Library version 2.19 is now available
1–10 of 14 posts
Re: The GNU C Library version 2.19 is now available
#2[deleted]
Re: The GNU C Library version 2.19 is now available
#3The glibc team are great people to work with; I managed to get a patch into this release which had been point blank refused by Ulrich Drepper when he was maintainer, and they were incredibly helpful and the process was really easy. So get your fixes in - glibc is becoming much more standards compliant.
Assholes will ruin your project[1], you need to get rid of them, whether it is open source or not.
Re: The GNU C Library version 2.19 is now available
#4The glibc team are great people to work with; I managed to get a patch into this release which had been point blank refused by Ulrich Drepper when he was maintainer, and they were incredibly helpful and the process was really easy. So get your fixes in - glibc is becoming much more standards compliant. Assholes will ruin your project[1], you need to get rid of them, whether it is open source or not. [1] http://www.yo…
What was the patch?
Re: The GNU C Library version 2.19 is now available
#5The glibc team are great people to work with; I managed to get a patch into this release which had been point blank refused by Ulrich Drepper when he was maintainer, and they were incredibly helpful and the process was really easy. So get your fixes in - glibc is becoming much more standards compliant. Assholes will ruin your project[1], you need to get rid of them, whether it is open source or not. [1] http://www.yo…
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."
Re: The GNU C Library version 2.19 is now available
#6It's like beating a dead horse.
Re: The GNU C Library version 2.19 is now available
#7Earlier quoted context omitted.
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."
Yeah thats the one.
Re: The GNU C Library version 2.19 is now available
#8Earlier quoted context omitted.
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).
Re: The GNU C Library version 2.19 is now available
#9Earlier 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…
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.
Re: The GNU C Library version 2.19 is now available
#10Earlier 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…
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.