Our great sponsors
-
printf
Tiny, fast, non-dependent and fully loaded printf implementation for embedded systems. Extensive test suite passing.
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
libc
libc targeted for embedded systems usage. Reduced set of functionality (due to embedded nature). Chosen for portability and quick bringup. (by embeddedartistry)
-
supermin
tool for creating supermin appliances (formerly called febootstrap). PLEASE DO NOT USE GITHUB FOR ISSUES OR PULL REQUESTS. See the website for how to file a bug or contact us. http://libguestfs.org
Seems unlikely. My spot check of the the two vfprintf implementations shows no flow from one to the other, and shows that part of the Cosmopolitan code has an older lineage than nolibc.
The nolibc source has many reference to copyright held by "Willy Tarreau", under LGPL-2.1 OR MIT license, with a copyright date starting in 2017.
The string "Tarreau" does not exist in the Cosmopolitan library, so that's a strong negative there. Let's look closer.
The file organization is quite different. And so is the implementation. So that's another negative.
Compare the vfprintf in nolibc at https://elixir.bootlin.com/linux/v6.2-rc4/source/tools/inclu... (a 'minimal vfprintf()') with the one in cosmopolitan starting at https://github.com/jart/cosmopolitan/blob/master/libc/stdio/....
Right away we can see nolibc places many functions in the same file while Cosmopolitan uses a one-function-per-filename organization.
Cosmopolitan's fvprintf locks the file (which nolibc doesn't need to do) then calls vfprintf_unlocked which calls __fmt at https://github.com/jart/cosmopolitan/blob/master/libc/fmt/fm... , which is the actual implementation. It look very different from NOLIBC's.
Okay, so perhaps that's they way now but not at the beginning?
We can also go back to Cosmopolitan's original implementation and see how vfprintf goes through https://github.com/jart/cosmopolitan/blob/c91b3c50068224929c... to call "palandprintf", which https://github.com/jart/cosmopolitan/blob/c91b3c50068224929c... says is copyright "Marco Paland" from 2014-2019.
That's a few years older than the start of nolibc, available from https://github.com/mpaland/printf , and part of https://github.com/embeddedartistry/libc , a "libc targeted for embedded systems usage".
Thus, multiple factors seem to agree that nolibc code is not used in the Cosmopolitan library.
Seems unlikely. My spot check of the the two vfprintf implementations shows no flow from one to the other, and shows that part of the Cosmopolitan code has an older lineage than nolibc.
The nolibc source has many reference to copyright held by "Willy Tarreau", under LGPL-2.1 OR MIT license, with a copyright date starting in 2017.
The string "Tarreau" does not exist in the Cosmopolitan library, so that's a strong negative there. Let's look closer.
The file organization is quite different. And so is the implementation. So that's another negative.
Compare the vfprintf in nolibc at https://elixir.bootlin.com/linux/v6.2-rc4/source/tools/inclu... (a 'minimal vfprintf()') with the one in cosmopolitan starting at https://github.com/jart/cosmopolitan/blob/master/libc/stdio/....
Right away we can see nolibc places many functions in the same file while Cosmopolitan uses a one-function-per-filename organization.
Cosmopolitan's fvprintf locks the file (which nolibc doesn't need to do) then calls vfprintf_unlocked which calls __fmt at https://github.com/jart/cosmopolitan/blob/master/libc/fmt/fm... , which is the actual implementation. It look very different from NOLIBC's.
Okay, so perhaps that's they way now but not at the beginning?
We can also go back to Cosmopolitan's original implementation and see how vfprintf goes through https://github.com/jart/cosmopolitan/blob/c91b3c50068224929c... to call "palandprintf", which https://github.com/jart/cosmopolitan/blob/c91b3c50068224929c... says is copyright "Marco Paland" from 2014-2019.
That's a few years older than the start of nolibc, available from https://github.com/mpaland/printf , and part of https://github.com/embeddedartistry/libc , a "libc targeted for embedded systems usage".
Thus, multiple factors seem to agree that nolibc code is not used in the Cosmopolitan library.
Seems unlikely. My spot check of the the two vfprintf implementations shows no flow from one to the other, and shows that part of the Cosmopolitan code has an older lineage than nolibc.
The nolibc source has many reference to copyright held by "Willy Tarreau", under LGPL-2.1 OR MIT license, with a copyright date starting in 2017.
The string "Tarreau" does not exist in the Cosmopolitan library, so that's a strong negative there. Let's look closer.
The file organization is quite different. And so is the implementation. So that's another negative.
Compare the vfprintf in nolibc at https://elixir.bootlin.com/linux/v6.2-rc4/source/tools/inclu... (a 'minimal vfprintf()') with the one in cosmopolitan starting at https://github.com/jart/cosmopolitan/blob/master/libc/stdio/....
Right away we can see nolibc places many functions in the same file while Cosmopolitan uses a one-function-per-filename organization.
Cosmopolitan's fvprintf locks the file (which nolibc doesn't need to do) then calls vfprintf_unlocked which calls __fmt at https://github.com/jart/cosmopolitan/blob/master/libc/fmt/fm... , which is the actual implementation. It look very different from NOLIBC's.
Okay, so perhaps that's they way now but not at the beginning?
We can also go back to Cosmopolitan's original implementation and see how vfprintf goes through https://github.com/jart/cosmopolitan/blob/c91b3c50068224929c... to call "palandprintf", which https://github.com/jart/cosmopolitan/blob/c91b3c50068224929c... says is copyright "Marco Paland" from 2014-2019.
That's a few years older than the start of nolibc, available from https://github.com/mpaland/printf , and part of https://github.com/embeddedartistry/libc , a "libc targeted for embedded systems usage".
Thus, multiple factors seem to agree that nolibc code is not used in the Cosmopolitan library.
He briefly mentions dietlibc ("not evolving anymore") and ulibc. I think he'd be better off contributing to those projects.
FWIW I have built a program that needs a tiny initramfs[1] and we've found that dietlibc and musl worked really well in producing very tiny programs. Using glibc is terrible however - it links huge amounts of code into even the smallest program.
[1] https://github.com/libguestfs/supermin/blob/86fd6f3e86ab99d5...