It uses format strings and the default LOG_ is just printf()

Murdock results

✔️ PASSED

3237ed9 core/panic: don't use LOG_ functions in panic handler

Artifacts

• Documentation preview

Maybe it would have made sense to add a comments somewhere in that file that LOG_* is not used for a reason. Preventing anyone in the future trying to get rid of printfs from making the same mistake again.

For clarification: How is LOG_ more reliable than stdout? Just like logging can be redirected, stdio can be, eg. by going through BLE or to the VFS, and that'd just run into the same issue.

@benpicco ^

For reference, this creates a hard dependency on libc stdio formatting code. LOG_ was used here in the first place to remove that dependency (so tests/minimal gets smaller).

I'm not so concerned about minimal binary size with DEVELHELP=1

I agree that stdio can have the same problem, but we could introduce a flag field to stdio_provider_t so that we could skip high-level stdio implementations in case of panic.

That could also solve the issue brought up in #20364 (comment)

I'm not so concerned about minimal binary size with DEVELHELP=1

This is independent of DEVELHELP, core/panic now always uses printf(). Previously, it was possible to skip linking any stdio code by setting -DLOG_LEVEL=LOG_NONE (for core and non-printf using code).

That's just by chance - any module using stdio would void that again - lets rather solve the problem properly by turning all calls to printf() into a no-op when stdio_null is used.
#20872