3 ms·

glibc in total is about 460.000 lines of C. If we're planning on reimplementing it as a whole that's going to be quite an undertaking. Musl is an alternative li

by tinco 11y ago

glibc in total is about 460.000 lines of C. If we're planning on reimplementing it as a whole that's going to be quite an undertaking. Musl is an alternative libc that's only about 60.000 lines of C. I don't know exactly why libc is that much larger, as musl also aims to be a complete and POSIX compatible libc. Its getaddrinfo is considerably smaller at 90 lines, and there's no goto's, it looks comfortably readable at a glance. Maybe a nice blog post would be to compare both implementations to find out if there's a concrete difference in functionality and code quality. edit: I should've looked at the 2nd Google result, it's a complete comparison of a bunch of libc's: http://www.etalabs.net/compare_libcs.html http://www.etalabs.net/compare_libcs.html

michaelmior 11y ago
I think Musl would probably be a better starting point for a libc rewrite. It would be cool if people were willing to take this on.
pm215 11y ago
Some of that will be glibc's coverage of a much wider range of architectures and host OSes than musl (a very back-of-the-envelope wc -l suggests that somewhere between 20 and 25% of glibc code is in sysdeps/ or ports/sysdeps/), but that's clearly not the only thing contributing to glibc being bigger.
- belorn 11y ago
  There is also GNU specific functions and macros in glibc. Is musl implementing _GNU_SOURCE? I know that my own project use TEMP_FAILURE_RETRY macro quite heavily, among with asprintf.
hawski 11y ago
This comparison is mentioned here or there, but it is important to add that it's not that recent. musl 1.1.5 was released on October 2014 glibc 2.19 was released on February 2014 Author of that page should probably add at the top of the page big header "2014". I can't find contact info to ask of him to do that though.
- cremno 11y ago
  The author is Rich Felker (the musl developer).
chrissnell 11y ago
Correct me if I'm wrong here but the CVE-2015-7547 vulnerability covered code that fell into "libresolv"--at least under Ubuntu. This is a smaller subset of glibc that would take far less effort than a re-implemtation of the glibc in its entirety.
Sanddancer 11y ago
One of the things I'm noticing in looking through the musl code in comparison to FreeBSD's libc (yes, it's not glibc, but it's also a full-featured libc) is that musl makes a lot more assumptions about the base system and the results it gets back. Looking through getaddrinfo.c, musl doesn't handle systems that don't have ipv6 enabled, doesn't document the tricky corner cases of the RFCs that cover name resolution, doesn't check for order of precedence, doesn't handle site local address ranges, etc. Other sticky points offhand look like a much lower amount of i18n support in musl, the inclusion of floating point emulation in the bigger C libraries, and other bits and pieces that are useful when you find yourself on platforms that aren't as full featured as other architectures. Aditionally, individual files in musl do not carry licensing and other information, which again pushes up counts of code length. This is just a 10000 foot view of the two, but hopefully is helpful in starting to explain why musl's small size may not be all that advantageous if you want the kind of coverage a libc like glibc or freebsd libc has.

by tinco 11y ago

michaelmior 11y ago

I think Musl would probably be a better starting point for a libc rewrite. It would be cool if people were willing to take this on.

pm215 11y ago

Some of that will be glibc's coverage of a much wider range of architectures and host OSes than musl (a very back-of-the-envelope wc -l suggests that somewhere between 20 and 25% of glibc code is in sysdeps/ or ports/sysdeps/), but that's clearly not the only thing contributing to glibc being bigger.

belorn 11y ago
There is also GNU specific functions and macros in glibc. Is musl implementing _GNU_SOURCE? I know that my own project use TEMP_FAILURE_RETRY macro quite heavily, among with asprintf.

hawski 11y ago

This comparison is mentioned here or there, but it is important to add that it's not that recent. musl 1.1.5 was released on October 2014 glibc 2.19 was released on February 2014 Author of that page should probably add at the top of the page big header "2014". I can't find contact info to ask of him to do that though.

cremno 11y ago
The author is Rich Felker (the musl developer).

chrissnell 11y ago

Correct me if I'm wrong here but the CVE-2015-7547 vulnerability covered code that fell into "libresolv"--at least under Ubuntu. This is a smaller subset of glibc that would take far less effort than a re-implemtation of the glibc in its entirety.

Sanddancer 11y ago

One of the things I'm noticing in looking through the musl code in comparison to FreeBSD's libc (yes, it's not glibc, but it's also a full-featured libc) is that musl makes a lot more assumptions about the base system and the results it gets back. Looking through getaddrinfo.c, musl doesn't handle systems that don't have ipv6 enabled, doesn't document the tricky corner cases of the RFCs that cover name resolution, doesn't check for order of precedence, doesn't handle site local address ranges, etc. Other sticky points offhand look like a much lower amount of i18n support in musl, the inclusion of floating point emulation in the bigger C libraries, and other bits and pieces that are useful when you find yourself on platforms that aren't as full featured as other architectures. Aditionally, individual files in musl do not carry licensing and other information, which again pushes up counts of code length. This is just a 10000 foot view of the two, but hopefully is helpful in starting to explain why musl's small size may not be all that advantageous if you want the kind of coverage a libc like glibc or freebsd libc has.