
Picolibc – Libc for Embedded Systems - homarp
https://keithp.com/blogs/picolibc/
======
AceJohnny2
I wish we could do away with (parts of) libc entirely. Many of its design
principles and limitations date back to its inception and don't make sense
today, even on "embedded" systems.

\- function names limited to 6 characters (because of compiler/linker memory
limits at the time?)

\- non-reentrency of many functions (strtok(), errno...)

\- dangerous string manipulation functions (see the various iterations of
strcpy())

\- and so much more...

Of course, I'm missing the point. Libc continues on because it's standard and
backwards-compatible, and lets you leverage 50 years of software ecosystem.

Nevertheless, I'd love to see what a modern clean-slate implementation might
look like. I'm sure there'd be much disagreement about what warrants
replacement and what doesn't ;)

~~~
wahern
> I'm sure there'd be much disagreement about what warrants replacement and
> what doesn't ;

How many backwards incompatible variations of C++ std::string have there been,
simply in terms of the standard (not extensions). Two? Three?

glibc has been turning their nose up at strlcpy(3) for literally 20 years, and
yet _still_ doesn't provide a comparable one-liner alternative that guarantees
to always leave a NUL-terminated string behind (i.e. doesn't leave a loaded
gun lying around).

A good string interface is impossible to pin down because a "string" is the
anti-thesis of a proper data structure. C dipped its toes in the better string
library waters with Annex K, which saw almost no uptake; even the original
sponsor, Microsoft, never shipped a complete implementation. C would be wise
to avoid chasing the mirage of a better string library. In general if you're
thinking in terms of "strings", C is the wrong language. C being an
inconvenient language for programming with that mindset is a good thing.

(I would love to see strlcpy added, but the fact it's so divisive is maybe a
strong hint that there's no way to placate a substantial minority of people,
not even the most pragmatic of users. Anything involving the str* API is a
lose-lose at this point.)

What C really needs are some primitives for bounded arrays and slices. There
are some very good, very simple proposals out there, but no compiler vendor
has actually shipped them and the C committee has been burned several times
before by standardizing de novo interfaces.

~~~
ComputerGuru
Regarding strlcpy and co
[https://developers.redhat.com/blog/2019/08/12/efficient-
stri...](https://developers.redhat.com/blog/2019/08/12/efficient-string-
copying-and-concatenation-in-c/)

------
jbuzbee
If you missed it, this is from Keith Packard, big-time X Window System
developer.

[https://en.wikipedia.org/wiki/Keith_Packard](https://en.wikipedia.org/wiki/Keith_Packard)

------
Ecco
The biggest news is probably the fact that it's BSD licensed. Having some GPL
parts had driven me away from newlib before.

~~~
delinka
If I were in the market for such a library, I'd still have serious concerns.
The GPL license still appears in the root of the repo as if the entire
codebase might be subject to GPL; It appears to be a fork of newlib (GPL) and
that means it might not qualify as a "clean room implementation" of GPL'd code
- the legal team in a corporation is going to insist on a ton of due diligence
on Picolibc before they allow it to be used.

~~~
derefr
Quoting the README:

> Remove[d] unused code with non-BSD licenses. There's still a pile of unused
> code hanging around, but all non-BSD licensed bits have been removed to make
> the licensing situation clear. Picolibc is BSD licensed.

From my understanding, Newlib is a GPL-licensed _project_ that has some GPL-
licensed _contributions_ and some BSD-licensed _contributions_ (in the sense
that these aren't original code written by contributors, but rather are copy-
and-paste inclusions of pieces from various GPL- and BSD-licensed codebases.)

The author created Picolibc by (doing the moral equivalent of) cherry-picking
out a small base of the commits to Newlib—all of which were copy-and-pastes
from BSD-licensed codebases.

\---

In some sense, Newlib is very similar to how a Linux distro works, repackaging
upstream code components (of various licenses) together.

Picolibc, then, would be a lot like creating a new Linux distro, derived
"from" Ubuntu, that happens to use only the packages in Ubuntu that are
themselves directly copied in from upstream Debian (pretending for a moment
that Ubuntu does this rather than re-signing packages with their own keys.) Is
such a distro really "derived from Ubuntu"? Or is it derived "from" Debian,
with an Ubuntu mirror server just serving as a pipe that some _Debian_
packages went through on their trip "from" Debian's hands "into" the hands of
the new distro?

\---

Either way, worries that the GPL could infect this effort are misplaced—even
if it comes to a legal battle, at any point, the same codebase could be
recreated (with a bit of a schlep) by just going to all the same BSD-licensed
upstream sources that Newlib's contributors pulled from, and doing the same
copy-and-pasting that Newlib's contributors did.

------
alexhutcheson
Most of the big chip vendors provide a libc implementation along with the
proprietary compilers that they maintain for their chips. On the TI MSP430,
I've had some projects that were too big to fit into flash if I used the libc
(newlib) that's bundled with the open source MSP430-GCC compiler[1]. By
contrast, if I compiled with the proprietary TI compiler[2] and its libc, the
binary was small enough to fit. My experience is a bit dated at this point, so
newlib and the GCC fork may have improved enough to reach parity by now.

The dominance of GCC and LLVM on x86[-64] machines has conditioned many of us
to take great open source build toolchains for granted, but embedded systems
are comparatively the wild west - there are still a lot of proprietary build
toolchains out there. Obviously this is a negative if you're committed to
using open source tools, but one positive is that it's a niche where companies
can still make money selling compilers (and therefore employing engineers who
work on compilers).

[1] [http://www.ti.com/tool/MSP430-GCC-
OPENSOURCE](http://www.ti.com/tool/MSP430-GCC-OPENSOURCE)

[2] [http://www.ti.com/tool/MSP-CGT](http://www.ti.com/tool/MSP-CGT)

------
ChuckMcM
This is an excellent libc for embedded systems. I am looking to add it to a
self hosted tcc (Bellard's C compiler) on ARM Cortex-M systems.

------
snops
An interesting non-free alternative is the SEGGER Runtime Library [1] which
works with GCC, but with smaller code size than newlib-nano and significantly
faster floating point emulation [2] for processors like the Cortex M3 or RISCV
wih no FPU. It would be interesting to see if newlib-nano or picolibc could
use these tricks.

[1] [https://www.segger.com/products/development-tools/runtime-
li...](https://www.segger.com/products/development-tools/runtime-library/) [2]
[https://blog.segger.com/floating-point-face-
off/](https://blog.segger.com/floating-point-face-off/)

------
pantalaimon
Looks like it can save a good chunk of memory compared to newlib:
[https://github.com/RIOT-OS/RIOT/pull/12305](https://github.com/RIOT-
OS/RIOT/pull/12305)

------
stock_toaster
I didn't see this addressed in the post, but why not musl?

~~~
fra
For what it's worth: musl is much larger than newlib-nano or picolibc. Most of
the embedded projects I've worked on could not afford to use musl.

~~~
weberc2
So the inverse--could an OS distribution like alpine profit from using picolib
instead of musl? What would be the tradeoffs (presumably performance for size,
but to what degree)?

~~~
simcop2387
Along with performance, there's probably other ABI issues and maybe even API
extensions to the C library that just aren't present in these tiny
implementations. You can work around the ABI stuff by recompiling with the new
c library of course, but that won't work if you've got a closed source binary
or if the software needs something not provided.

------
nerpderp82
Needs to have a strong overlap with WASI.

~~~
saagarjha
Why?

