4 ms·

This is great advice, since in general you would like to assume that the standard library is implemented well, i.e. by people who know the target language. Unf

by unwind 13y ago

This is great advice, since in general you would like to assume that the standard library is implemented well, i.e. by people who know the target language. Unfortunately, for C this is pretty hard to do, at least for the GNU libc. I'm not trying to critique the implementation, but every time I dive in (generally to help someone on Stack Overflow) I'm confused and get to spend a lot of time searching the code. It's obviously optimized for a great deal of other parameters before ease of reading, which I totally understand yet still am a bit sorry to see.

asveikau 13y ago
I don't remember the last time I looked at glibc source so I am not sure if I can relate to this comment or not. However, I just wanted to throw in that I find the various *BSD projects, including their libcs, very readable. It helps that everything is in a single tree with some consistency in naming patterns etc, and the style is usually decent.
- clarry 13y ago
  I just have to second this. I have a checkout of the OpenBSD source tree on all my machines. While tinkering with stuff, I often end up browsing the code under libc/, with great curiosity. Though there are many not-quite-so-pretty bits inherited from the dark ages, I can't say I've ever really felt confused. On the contrary, there's plenty of nice, inspiring code just waiting to be read. Oh, and there's superb documentation to go with it.
NAFV_P 13y ago
I was reading stdio.h and stdlib.h yesterday, because I wanted to know the macro definition which prevents multiple includes. The code seems a bit 'organic', like it was cultured in a petri dish.
- maaku 13y ago
  It's an apt description as that code did grow and evolve, constrained by natural selection - only those changes which could be safely made without breaking or even changing functionality on hundreds of architectures over thousands of platforms ever made it in. Naturally that means it is an ever growing assortment of carefully vetted but otherwise horribly ugly hacks.
  - NAFV_P 13y ago
    I thought the headers looked wicked, like a bizarre fantasy wilderness populated with fairies and leprechauns.
chubot 13y ago
Yeah, a lot of good programmers have alternatives to libc, either for reasons of history or taste. I was just reading DJB's daemontools (less than 6K LOC, very tidy!), and he doesn't use libc. Actually his code has been collected in libdjb, which seems quite nice: http://www.fefe.de/djb/ http://www.fefe.de/djb/ And also the Plan 9 / Go guys don't use ANSI libc as far as I remember. Those are two examples of people who don't even use the ANSI libc interface. But there are plenty of people who don't use GNU libc, and use uclibc or various other source-compatible alternatives. I think Debian switched to eglibc awhile ago.
- rat87 13y ago
  I'm pretty sure eglibc(Embedded GLIBC) is basically a patchset for glibc for certain distros(especially debian and derivatives) because they disagreed with the maintainer especially over ARM support.
- burntsushi 13y ago
  Just FYI, I believe that by default, binaries compiled with the standard Go toolchain do link against your system's libc (which is probably GNU libc on Linux). However, I believe that can be disabled by compiling the Go toolchain with `CGO_ENABLED=0` set. But you might lose some functionality.[1] [1] - https://groups.google.com/forum/#!msg/golang-nuts/H-NTwhQVp-8/i5vhUB5dZ5QJ https://groups.google.com/forum/#!msg/golang-nuts/H-NTwhQVp-...
  - chubot 13y ago
    So I'm actually talking about what the Go compilers themselves use for libc, not Go programs. From what I can tell it is: http://code.google.com/p/go/source/browse/include/libc.h http://code.google.com/p/go/source/browse/include/libc.h Which is definitely not ANSI libc. Go programmers won't care about this, because it's an implementation detail, but we're talking about reading source code.
    - burntsushi 13y ago
      Ah! Mea culpa. I completely misunderstood your initial comment then. You're absolutely right.
userbinator 13y ago
You might be interested in this: http://hg.pdclib.e43.eu/pdclib http://hg.pdclib.e43.eu/pdclib It's a public domain C library, much smaller and less of a monster than glibc, plus you don't have to worry about any implications of reading GPL code.
- alextingle 13y ago
  Tell me more of these "implications of reading GPL code".
ori_b 13y ago
I suggest looking at musl libc: http://git.musl-libc.org/cgit/musl/tree http://git.musl-libc.org/cgit/musl/tree

by unwind 13y ago

asveikau 13y ago

I don't remember the last time I looked at glibc source so I am not sure if I can relate to this comment or not. However, I just wanted to throw in that I find the various *BSD projects, including their libcs, very readable. It helps that everything is in a single tree with some consistency in naming patterns etc, and the style is usually decent.

clarry 13y ago
I just have to second this. I have a checkout of the OpenBSD source tree on all my machines. While tinkering with stuff, I often end up browsing the code under libc/, with great curiosity. Though there are many not-quite-so-pretty bits inherited from the dark ages, I can't say I've ever really felt confused. On the contrary, there's plenty of nice, inspiring code just waiting to be read. Oh, and there's superb documentation to go with it.

NAFV_P 13y ago

I was reading stdio.h and stdlib.h yesterday, because I wanted to know the macro definition which prevents multiple includes. The code seems a bit 'organic', like it was cultured in a petri dish.

maaku 13y ago
It's an apt description as that code did grow and evolve, constrained by natural selection - only those changes which could be safely made without breaking or even changing functionality on hundreds of architectures over thousands of platforms ever made it in. Naturally that means it is an ever growing assortment of carefully vetted but otherwise horribly ugly hacks.
- NAFV_P 13y ago
  I thought the headers looked wicked, like a bizarre fantasy wilderness populated with fairies and leprechauns.

chubot 13y ago

Yeah, a lot of good programmers have alternatives to libc, either for reasons of history or taste. I was just reading DJB's daemontools (less than 6K LOC, very tidy!), and he doesn't use libc. Actually his code has been collected in libdjb, which seems quite nice: http://www.fefe.de/djb/ http://www.fefe.de/djb/ And also the Plan 9 / Go guys don't use ANSI libc as far as I remember. Those are two examples of people who don't even use the ANSI libc interface. But there are plenty of people who don't use GNU libc, and use uclibc or various other source-compatible alternatives. I think Debian switched to eglibc awhile ago.

rat87 13y ago
I'm pretty sure eglibc(Embedded GLIBC) is basically a patchset for glibc for certain distros(especially debian and derivatives) because they disagreed with the maintainer especially over ARM support.
burntsushi 13y ago
Just FYI, I believe that by default, binaries compiled with the standard Go toolchain do link against your system's libc (which is probably GNU libc on Linux). However, I believe that can be disabled by compiling the Go toolchain with `CGO_ENABLED=0` set. But you might lose some functionality.[1] [1] - https://groups.google.com/forum/#!msg/golang-nuts/H-NTwhQVp-8/i5vhUB5dZ5QJ https://groups.google.com/forum/#!msg/golang-nuts/H-NTwhQVp-...
- chubot 13y ago
  So I'm actually talking about what the Go compilers themselves use for libc, not Go programs. From what I can tell it is: http://code.google.com/p/go/source/browse/include/libc.h http://code.google.com/p/go/source/browse/include/libc.h Which is definitely not ANSI libc. Go programmers won't care about this, because it's an implementation detail, but we're talking about reading source code.
  - burntsushi 13y ago
    Ah! Mea culpa. I completely misunderstood your initial comment then. You're absolutely right.

userbinator 13y ago

You might be interested in this: http://hg.pdclib.e43.eu/pdclib http://hg.pdclib.e43.eu/pdclib It's a public domain C library, much smaller and less of a monster than glibc, plus you don't have to worry about any implications of reading GPL code.

alextingle 13y ago
Tell me more of these "implications of reading GPL code".

ori_b 13y ago

I suggest looking at musl libc: http://git.musl-libc.org/cgit/musl/tree http://git.musl-libc.org/cgit/musl/tree