[PATCH] ash: support platforms that don't have '%m' printf specifier

Denys Vlasenko vda.linux at googlemail.com
Fri Jul 28 13:52:40 UTC 2017


On Thu, Jul 27, 2017 at 6:58 PM, Jody Bruchon <jody at jodybruchon.com> wrote:
> On 2017-07-27 12:16, Xabier Oneca -- xOneca wrote:
>>
>> Hello:
>>
>> 2017-07-27 17:48 GMT+02:00 Ron Yorston <rmy at pobox.com>:
>>>
>>> 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.

That's how standards evolve.
Something appears in one implementation. If it's useful,
there is pressure for other implementations to copy it.
Eventually, standards codify it.

> save a couple of bytes

is still one of the goals of the project. Yes, it makes sense to not be
too carried away with it (look at tftp.c or ubi_tools.c for counter-examples),
but Ron's patch does not seriously impact readability.


More information about the busybox mailing list