
The GNU C Library version 2.20 - lelf
http://lists.gnu.org/archive/html/info-gnu/2014-09/msg00003.html
======
ausjke
The first release since eglibc merged back to glibc, cool.

------
beefhash
One day we'll get strlcpy and strlcat for sure. Just not here, not now.

~~~
__david__
Or the C11 safe string functions. It depresses me that they aren't already
there...

~~~
stephencanon
Don’t use implicit length strings at all. Use one of the various better string
libraries, or use explicit length + buffer representations with memcpy and
friends. Safer _and_ faster than any of the “safe” string APIs.

------
JoshTriplett
> Support for loadable gconv transliteration modules has been removed.

And there was much rejoicing.

~~~
gioele
> > Support for loadable gconv transliteration modules has been removed.

> And there was much rejoicing.

Could you explain why?

~~~
JoshTriplett
That gconv module support involved loading shared libraries from a special
directory (for instance, /usr/lib/x86_64-linux-gnu/gconv/ on systems using
multiarch paths, such as Debian). This had several problems:

1) glibc supported this even if statically linked, and could encounter runtime
issues if the gconv modules found did not match glibc. For instance, if you
shipped a statically linked binary.

2) glibc can handle not finding these modules at all, but once it finds them,
if they fail to work glibc can choke and die.

3) These modules take up quite a lot of space, and glibc installs them by
default. If you're building a space-constrained or embedded system, you'd want
to remove them.

------
GFK_of_xmaspast
Was glibc the project with the super-toxic guy involved?

~~~
SEJeff
Yup, Ulrich Drepper, as well meaning as he was, was known to be quite toxic. A
small group of developers now all co-maintain glibc to prevent that sad state
of affairs from ever repeating.

~~~
_delirium
As someone who has never interacted with him, an interesting thing about
Drepper on HN is that I see him linked in two contexts with diametrically
opposite valences: 1) short flamey exchanges on mailing lists or in bug-report
threads; and 2) long and quite good articles, for example this one:
[https://software.intel.com/sites/default/files/m/e/9/7/cpume...](https://software.intel.com/sites/default/files/m/e/9/7/cpumemory.pdf)

~~~
angersock
People skills and programming skills do not necessarily correlate. See also
Linus Torvalds and Steve Jobs.

~~~
beagle3
Linus Torvalds aces both programming and people skills, and in most senses
Steve Jobs did too: They are(were) both dictators, but they mobilize(d) and
co-ordinate(d) thousands of people into creating impressive bodies of work.

I hold Torvalds in much, much higher regard than Jobs in this respect, because
-- unlike Jobs who got co-operation and loyalty mostly in return for money,
Torvalds has been able to do so without being the benefactor of the
contributors he co-ordinates.

Torvalds can and does write the occasional scathing email, and that's what
makes the news and creates the impression - but he actually does that when
it's needed to drive a point (and when asked about it he explained more than
once - being subtle in a mailing list read by thousands simply does not work).
Most of the time, he is a nice, considerate and appreciative.

Torvalds has amazing people skills, even if occasionally he rubs some people
the wrong way. I would say the same about Jobs, even if I disagree with his
way. You just can't get thousands of people to do stuff, money or not, unless
you have people skills.

Drepper in his capacity as libc maintainer was none of this.

~~~
angersock
So, in the Jobs case, his programming skills/engineering skills were basically
nonexistent. He had a lot of opinions, and had very good people skills, but he
was a joke of an engineer.

~~~
SEJeff
Jobs was a designer, not an engineer. Wozniak was the software developer for
Steve Jobs. It isn't that Steve Jobs was a joke of an engineer so much as
Steve Jobs was _not_ an engineer. He was a charismatic leader who inspires
people to push themselves to and potentially past the breaking point.

When you can inspire people to push themselves harder than they would push
themselves normally, you tend to see a lot of greatness. The way he did it was
basically to be a sociopath however, which is unfortunate for all who worked
directly with him.

~~~
angersock
He was a con man and ripped Wozniak off during a stint working for Atari--
while theoretically being an engineer. I'll stand by my statement.

------
nteon
The _DEFAULT_SOURCE change is annoying. Well maintained C codebases that use
-Werror combined with _BSD_SOURCE are now broken until they add the additional
_DEFAULT_SOURCE define to their build, like Go:
[https://code.google.com/p/go/source/detail?r=c8059ac4e0ec](https://code.google.com/p/go/source/detail?r=c8059ac4e0ec)

~~~
stefantalpalaru
And that's why you should never use -Werror by default, regardless of how well
maintained your code is.

~~~
JoshTriplett
Yes, you absolutely should. If you need to disable errors for specific
warnings, use (for instance) -Werror=no-deprecated-declarations ; however,
projects that build without Werror in general tend to fail to actually fix
warnings, resulting in an overwhelming pile of them.

If you don't feel comfortable turning all warnings into errors, then use
-Werror=some-warning and -Werror=some-other-warning to turn specific warnings
into errors, to make sure those particular warnings never get into the
project.

~~~
__david__
That's a fine attitude to have for your development team, but if your source
releases to the general public use -Werror then you're doing it wrong. You're
practically guaranteeing that the code you ship won't build on your end user's
systems unless they happen to have whatever particular flavor of compiler that
you tested with. And in 6 months there will be due to new compiler warnings or
new libraries and your stable release will break unnecessarily.

-Werror is _much_ too fragile for production releases, stop foisting it on unsuspecting users.

------
izietto
I wonder what is the percentage rate of GNU C Lib presence inside free
software code. My guess is 95%.

~~~
JoshTriplett
If you mean the fraction of Linux systems using glibc: near-100% of non-
Android systems, but Android uses its own libc.

If you mean the fraction of software depending on glibc-specific features:
probably less than 50%, much less if you only count software that _meant_ to
depend on glibc-specific features.

~~~
Figs
A lot of routers, set-top boxes, and other embedded systems also use
alternative libcs, but I think you're right for Linux desktop and server
systems -- most of those either use glibc or a fork/variant like eglibc.

~~~
Alupis
Musl-libc and uClibc are probably the most popular right now.

