On Fri, Jul 28, 2017 at 12:58 AM, Jody Bruchon <j...@jodybruchon.com> wrote:

> IMO the whole issue is that %m is non-standard despite having moderate de
> facto acceptance in many libc implementations. I think BusyBox should comply
> with the standards instead of having a compile-time hack and added code
> complication to save a couple of bytes by switching to %m. There is no
> guarantee that a particular BusyBox binary built to use a library with %m
> won't be moved from that machine to one with the same libc but without %m
> built in (I don't know if dietlibc could bring such a situation to reality
> but it wouldn't surprise me.)

That's a good question, and a good reason to leave %m disabled in
default busybox build for dietlibc.

But better leave a comment line in platform.h there to state the reason.

> As far as I can see the only savings by using
> %m would be one parameter off of a [f]printf() and one function call to
> strerror() removed; how much is that really saving, and is it worth the
> added code complexity and the non-compliance with the standards?

The decision isn't by me, but it seems that BusyBox concerns more about
binary size than standard compliance. So we may use extensions when
they reduce the binary size, even by only a few bytes.
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Reply via email to