

The GNU C Library version 2.19 is now available - slashdotaccount
https://sourceware.org/ml/libc-alpha/2014-02/msg00224.html

======
justincormack
The 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.youtube.com/watch?v=-ZSli7QW4rg](http://www.youtube.com/watch?v=-ZSli7QW4rg)

~~~
chris_wot
What was the patch?

~~~
rquirk
Maybe this one? [http://sourceware.org/ml/libc-
alpha/2013-10/msg00870.html](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](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."

~~~
letzjuc
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).

~~~
jzwinck
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.

~~~
letzjuc
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.

