[HN Gopher] Picolibc: C library designed for embedded 32- and 64...
___________________________________________________________________
Picolibc: C library designed for embedded 32- and 64- bit systems
Author : ingve
Score : 72 points
Date : 2022-11-14 16:52 UTC (6 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| hulitu wrote:
| > Keith Packard
|
| Now, that is a name.
|
| Can this library be used as a replacement for glibc ?
| NelsonMinar wrote:
| More on Keith Packard's website: https://keithp.com/picolibc/
| dang wrote:
| Related:
|
| _Picolibc - Libc for Embedded Systems_ -
| https://news.ycombinator.com/item?id=21150678 - Oct 2019 (41
| comments)
| JohnKuzyarko wrote:
| bxparks wrote:
| 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?
| otikik wrote:
| Not bought by Musk yet :)
|
| 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.
| ixtenu wrote:
| 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.
| suprjami wrote:
| iirc Keith talked about other library comparisons in his LCA
| talk about picolibc: https://youtu.be/SC6aBezNFFQ
| TD-Linux wrote:
| 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.
| nerpderp82 wrote:
| 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.
| asveikau wrote:
| 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.
| AlotOfReading wrote:
| 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.
| makapuf wrote:
| I guess you're mentioning Greenspun's 10th rule,
| https://en.m.wikipedia.org/wiki/Greenspun%27s_tenth_rule:
|
| > Any sufficiently complicated C or Fortran program contains
| an ad hoc, informally-specified, bug-ridden, slow
| implementation of half of Common Lisp.
| kevin_thibedeau wrote:
| It's easy to avoid the functions with global state and Newlib
| can be built to minimize or eliminate their RAM consumption.
___________________________________________________________________
(page generated 2022-11-14 23:00 UTC)