On 2017-07-27 12:16, Xabier Oneca -- xOneca wrote:
Hello:
2017-07-27 17:48 GMT+02:00 Ron Yorston <[email protected]>:
Kang-Che Sung wrote:
dietlibc supports %m only if WANT_ERROR_PRINTF is defined in
<dietfeartures.h> when building, and its commented out by default.
I don't know how to check the macro WANT_ERROR_PRINTF in
the dietlibc build environment, but I think busybox needs to be
aware of this.
There doesn't seem to be anything in a standard build of dietlibc
to allow detection of this at (application) build-time. The
dietfeatures.h include file is only available when the library is
built; it isn't installed.
I suppose if the default is for '%m' to be disabled that's what
BusyBox should assume. If someone has built dietlibc with the
non-default option they should be capable of doing the same for
BusyBox.
Unless any dietlibc users have a better suggestion...
Ron
Try to compile a little application that uses this functionality and
check for success, as would be done with autoconf. Not suggesting to
do that, just giving ideas...
Cheers,
Xabier Oneca_,,_
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.) 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?
-Jody
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
