picolibc$ find . \( -name test -o -name testsuite \) -prune -o -name \*.c -exec cat -- {} + | wc -l 259227 picolibc$ find . \( -name test -o -name testsui

picolibc$ find . \( -name test -o -name testsuite \) -prune -o -name \*.c -exec cat -- {} + | wc -l 259227 picolibc$ find . \( -name test -o -name testsuite \) -prune -o -name \*.h -exec cat -- {} + | wc -l 60588 musl$ find . -name \*.c -exec cat -- {} + | wc -l 60697 musl$ find . -name \*.h -exec cat -- {} + | wc -l 37889 Those figures are sufficiently far apart that I don't think we need to quibble about comments. Whatever is causing those huge numbers for picolibc (architecture optimized function variations? per file license preambles?), suffice it to say that it's debatable the extent to which newlib or picolibc is smaller or simpler than musl, if at all. musl is maybe more ambitious in terms of full and correct POSIX compliance, but the code base is very clean and concise. For example, for locale support they keep things very simple by only supporting UTF-8. Unlike picolibc, musl includes a full ELF runtime dynamic linker, full pthreads library (with correct cancellation semantics!), and up-to-date wrappers for all the esoteric Linux syscalls, yet still clocks in at ~60k lines of C source files at most. It would be fairly trivial to remove those things, precisely because of how well structured and straightforward the code is. musl also builds using a single, simple Makefile musl$ wc -l Makefile 235 Makefile compared to the supposedly simpler and cleaner meson build: picolibc$ wc -l meson.build meson_options.txt 282 meson.build 132 meson_options.txt 414 total If I was working on an embedded project, I know which build I'd prefer to hack on.