5 ms·
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 emb
by nerpderp82 4y ago
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.
- kevin_thibedeau 4y agoIt's easy to avoid the functions with global state and Newlib can be built to minimize or eliminate their RAM consumption.
- smat 4y agoIs there a list of functions for newlib?
- AlotOfReading 4y agoGreenspun'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 4y agoI guess you're mentioning Greenspun's 10th rule, https://en.m.wikipedia.org/wiki/Greenspun%27s_tenth_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.
- asveikau 4y agoAll 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.