Bare Metal C vs. libc: Is the overhead worth it on small MCUs?

Oguz Kaan Ocal <[email protected]> Tue, 17 Mar 2026 08:52:24 +0300
Newsgroups alt.comp.lang.c
Organization A noiseless patient Spider
Message-ID <[email protected]>
Hey guys,

I've been debating this with myself for a while now. When you're working 
on resource-constrained hardware, do you guys actually use the standard 
C library (libc) or do you go full Bare Metal for everything?

I'm talking about things like using sprintf() vs. writing your own 
itoa(), or malloc() vs. static buffers. Even a simple printf() can bloat 
the binary by several KB and eat up the stack like crazy.

A few things I'm curious about:

Does anyone here still use the full standard library on chips with <32KB 
Flash? Or is it an immediate "no-go" for you?

For string manipulation (memcpy, memset, etc.), do you trust the 
compiler's built-in optimizations or do you write your own 
assembly/manual loops to save those extra cycles?

How do you handle things like dynamic memory? Is malloc() ever 
acceptable in a mission-critical embedded loop, or is it always static 
allocation only?

I feel like using the standard library is "cheating" and adds too much 
hidden overhead, but rewriting every basic utility feels like 
reinventing the wheel.

What's your take? Do you prefer the portability of standard C or the 
lean-and-mean performance of custom bare-metal implementations?