And because it's a fork of 'mirror/newlib-cygwin', searching for "picolibc" on GitHub does not find it, even though this project has 678 stars and the original newlib-cygwin has only 144 stars. Why is GitHub search so broken?
Seriously though: Making your fork "unhooked" from its parent is not very difficult, it only takes one support request and they usually get back to you within the week.
Independently of that, yes, search should find forks too.
What's the rationale for this project? In other words, what makes it different than other embedded libc projects like Newlib or uClibc-ng or musl? Not seeing any documentation which answers this question.
The biggest thing for me is the meson build system. newlib uses autoconf-generated files checked into the build tree, with several different versions of autoconf used depending on directory. So you have to keep several versions of autoconf around if you want to add e.g. another source file without churning the generated files.
I'm writing embedded bare-metal 64-bit arm code at work right now. That is because the product needs less than 300ms boot times from power on and needs to be fast enough to do image compression (AVIF) in a reasonable time. Just using Linux and suspend would eat too much battery from the power budget. It has to have 1 year of battery life like previous generation of that same product.
i.MX RT1170 with its 1Ghz 32Bit Cortex-M7 core was not fast enough so we had to jump up to much faster 64bit Cortex-A53 core.
Your guess is as good as mine. I assume it makes sense for running the test suite quickly before running it slowly, and for use with 64-bit baremetal raspberry pi, Atom, and their ilk.
Libc is an antipattern (me saying it makes it so, like a best practice) that has its own state, it should largely be avoided for everything, but most of all embedded applications.
All parts of libc are not created equal. Some bits have hard dependencies on OS functionality that would make it a no-go in embedded. Other pieces, like string functions, are 100% CPU with no syscalls -- no reason not to have a good, optimized memcpy on embedded.
Greenspun's rule also applies to libc's. I've seen far more bugs introduced by bad "bare metal" libc reimplementations than I've seen difficulties introduced by just using using a real libc.
I'm not sure what your alternative is to stateful runtimes and I'm very curious what such a thing would look like beyond the reentrant APIs already in most libcs. Even Go and Haskell use stateful runtimes above the OS e.g. allocators/GC.
