6 ms·

The GNU C Library version 2.20

72 points by lelf 12y ago

izietto 12y ago
I wonder what is the percentage rate of GNU C Lib presence inside free software code. My guess is 95%.
- dfox 12y ago
  That depends on how you define "presence" and "free software code". To cite from the article: "The GNU C Library is used as the C library in the GNU systems and is widely used on systems with the Linux kernel." That means that glibc is mostly used as part of desktop/server Linux distributions and not directly by software (although there is significant amount of both free and non-free software that depends on glibc-specific extensions or behavior).
- JoshTriplett 12y ago
  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 12y ago
    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 12y ago
      Musl-libc and uClibc are probably the most popular right now.
- kryptiskt 12y ago
  Most C code is written so it can be built with any POSIX C lib, otherwise the FreeBSD ports and Homebrew on OSX wouldn't be quite so extensive. Much is written so it can be built on Windows too, with only standard C library support.
JoshTriplett 12y ago
> Support for loadable gconv transliteration modules has been removed. And there was much rejoicing.
- gioele 12y ago
  > > Support for loadable gconv transliteration modules has been removed. > And there was much rejoicing. Could you explain why?
  - JoshTriplett 12y ago
    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.
beefhash 12y ago
One day we'll get strlcpy and strlcat for sure. Just not here, not now.
- nly 12y ago
  They're in libbsd, which is a dependency of Samba and therefore installed on most desktop distros. They just trade off one bug for another anyway.
- __david__ 12y ago
  Or the C11 safe string functions. It depresses me that they aren't already there...
  - fafner 12y ago
    The C11 safe string functions suffer from the fact that the error handling depends on a global state. The default states can either abort the application or make the functions return an error indicator. But IIRC the user can provide anything else for error handling as well. Therefore using them in a library comes with the risk of those functions handling errors different than you expected. Using them in the application comes with the risk of some library messing with it. That's why many people are opposed to them.
  - _delirium 12y ago
    Unfortunately the C11 safe string functions are part of an optional annex to the standard, not the standard per se, so are only quasi-standard. Afaik only Microsoft's standard library supports them, and other vendors have some skepticism about the design.
  - stephencanon 12y ago
    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.
nteon 12y ago
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 12y ago
  And that's why you should never use -Werror by default, regardless of how well maintained your code is.
  - JoshTriplett 12y ago
    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.
    - cygx 12y ago
      If you do use -Werror, provide an easy way for users to disable it via configure flag, environment or make variable. I'm using clang's -Werror -Weverything, which is obviously rather brittle. Building without -Werror is done via make NOWARN=error
    - mjg59 12y ago
      Shipping release code with -Werror is an invitation for future breakage when the compiler introduces a new warning. It makes absolute sense in the development tree.
    - __david__ 12y ago
      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.
ausjke 12y ago
The first release since eglibc merged back to glibc, cool.
GFK_of_xmaspast 12y ago
Was glibc the project with the super-toxic guy involved?
- JoshTriplett 12y ago
  I wish "the" were accurate, but yes, it was one such project. That maintainer has now been replaced by a group of friendly and active co-maintainers.
- SEJeff 12y ago
  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 12y ago
    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/cpumemory.pdf https://software.intel.com/sites/default/files/m/e/9/7/cpume...
    - angersock 12y ago
      People skills and programming skills do not necessarily correlate. See also Linus Torvalds and Steve Jobs.
      - mitchty 12y ago
        Yep, he was notorious for ignoring any change to make things work for non x86 platforms with responses akin to "only x86 matters".
      - beagle3 12y ago
        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.

72 points by lelf 12y ago

izietto 12y ago

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

dfox 12y ago
That depends on how you define "presence" and "free software code". To cite from the article: "The GNU C Library is used as the C library in the GNU systems and is widely used on systems with the Linux kernel." That means that glibc is mostly used as part of desktop/server Linux distributions and not directly by software (although there is significant amount of both free and non-free software that depends on glibc-specific extensions or behavior).
JoshTriplett 12y ago
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 12y ago
  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 12y ago
    Musl-libc and uClibc are probably the most popular right now.
kryptiskt 12y ago
Most C code is written so it can be built with any POSIX C lib, otherwise the FreeBSD ports and Homebrew on OSX wouldn't be quite so extensive. Much is written so it can be built on Windows too, with only standard C library support.

JoshTriplett 12y ago

> Support for loadable gconv transliteration modules has been removed. And there was much rejoicing.

gioele 12y ago
> > Support for loadable gconv transliteration modules has been removed. > And there was much rejoicing. Could you explain why?
- JoshTriplett 12y ago
  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.

beefhash 12y ago

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

nly 12y ago
They're in libbsd, which is a dependency of Samba and therefore installed on most desktop distros. They just trade off one bug for another anyway.
__david__ 12y ago
Or the C11 safe string functions. It depresses me that they aren't already there...
- fafner 12y ago
  The C11 safe string functions suffer from the fact that the error handling depends on a global state. The default states can either abort the application or make the functions return an error indicator. But IIRC the user can provide anything else for error handling as well. Therefore using them in a library comes with the risk of those functions handling errors different than you expected. Using them in the application comes with the risk of some library messing with it. That's why many people are opposed to them.
- _delirium 12y ago
  Unfortunately the C11 safe string functions are part of an optional annex to the standard, not the standard per se, so are only quasi-standard. Afaik only Microsoft's standard library supports them, and other vendors have some skepticism about the design.
- stephencanon 12y ago
  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.

nteon 12y ago

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 12y ago
And that's why you should never use -Werror by default, regardless of how well maintained your code is.
- JoshTriplett 12y ago
  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.
  - cygx 12y ago
    If you do use -Werror, provide an easy way for users to disable it via configure flag, environment or make variable. I'm using clang's -Werror -Weverything, which is obviously rather brittle. Building without -Werror is done via make NOWARN=error
  - mjg59 12y ago
    Shipping release code with -Werror is an invitation for future breakage when the compiler introduces a new warning. It makes absolute sense in the development tree.
  - __david__ 12y ago
    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.

ausjke 12y ago

The first release since eglibc merged back to glibc, cool.

GFK_of_xmaspast 12y ago

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

JoshTriplett 12y ago
I wish "the" were accurate, but yes, it was one such project. That maintainer has now been replaced by a group of friendly and active co-maintainers.
SEJeff 12y ago
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 12y ago
  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/cpumemory.pdf https://software.intel.com/sites/default/files/m/e/9/7/cpume...
  - angersock 12y ago
    People skills and programming skills do not necessarily correlate. See also Linus Torvalds and Steve Jobs.
    - mitchty 12y ago
      Yep, he was notorious for ignoring any change to make things work for non x86 platforms with responses akin to "only x86 matters".
    - beagle3 12y ago
      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.