Subject: [PATCH] strings: Correct output to be decimal per the help, instead of octal

[Tito]

On 10/14/2016 10:16 PM, Chris Renshaw wrote:
> *From:*busybox <busybox-bounces at busybox.net> on behalf of Tito
> <farmatito at tiscali.it>
>
> *Sent:* October 13, 2016 3:01 AM
> *To:* busybox at busybox.net
> *Subject:* Re: Subject: [PATCH] strings: Correct output to be decimal
> per the help, instead of octal
>
> On 10/12/2016 08:58 PM, Chris Renshaw wrote:
>> Hello!
>>
>>
>> They chose octal because they have -t (--radix) so other outputs may be
>> chosen as needed. The usual default for implementations that do not have
>> -t is decimal, reflected in busybox having this in the help for strings.
>> If someone could write full -t support that would of course be ideal,
>> but until then, decimal is the more common (and more useful) output.
>>
>>
>> Cheers,
>>
>> Chris
>>
>
> Hi,
> can you list some of this implementations that have this
> "usual default"?
>
> Ciao,
> Tito
>
> PS.: please don't top post.
>
>>
>> ------------------------------------------------------------------------
>> *From:* busybox <busybox-bounces at busybox.net> on behalf of Tito
>> <farmatito at tiscali.it>
>> *Sent:* October 11, 2016 3:38 PM
>> *To:* busybox at busybox.net
>> *Subject:* Re: Subject: [PATCH] strings: Correct output to be decimal
>> per the help, instead of octal
>>
>> On 10/11/2016 04:00 PM, Chris Renshaw wrote:
>>>>From fe9333ce1d69e292e14144a61ff88a23ffed0053 Mon Sep 17 00:00:00 2001
>>> From: Chris Renshaw <osm0sis at outlook.com>
>>> Date: Thu, 22 Sep 2016 16:17:05 -0300
>>> Subject: [PATCH] strings: Correct output to be decimal per the help, instead of octal
>>>  Most smaller/incomplete implementations of strings output decimal by default,
>>>  so best to correct that behavior rather than just change the help to say octal
>>>  (it would be great to get full POSIX --radix at some point, to give the
>>>  output in any desired format, but this will do for now)
>>>
>>> ---
>>>  miscutils/strings.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/miscutils/strings.c b/miscutils/strings.c
>>> index 9f50182..cc4ad9a 100644
>>> --- a/miscutils/strings.c
>>> +++ b/miscutils/strings.c
>>> @@ -68,7 +68,7 @@ int strings_main(int argc UNUSED_PARAM, char **argv)
>>>                                                        printf(fmt, *argv);
>>>                                                }
>>>                                                if (option_mask32 & PRINT_OFFSET) {
>>> -                                                     printf("%7"OFF_FMT"o ", offset - n);
>>> +                                                     printf("%7"OFF_FMT"d ", offset - n);
>>>                                                }
>>>                                                fputs(string, stdout);
>>>                                        }
>>>
>>
>>
>> Hi,
>> man STRINGS(1) GNU Development Tools binutils-2.25 says:
>>
>> "-o  Like -t o.  Some other versions of strings have -o act like -t d
>> instead.
>> Since we can not be compatible with both ways, we simply chose one."
>>
>> As we mimick GNU strings for linux maybe correcting the help would be
>> the better
>> option.
>>
>> Ciao,
>> Tito
>>
> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://lists.busybox.net/mailman/listinfo/busybox
>
> ------------------------------------------------------------------------
>
>
> Ah, sorry about the "top posting", it's the default in my mail client. :)
>
> Most prominently "toybox" also has a similarly limited strings
> implementation and has decimal as the only offset output, also, on
> Android several OEMs have previously implemented strings as part of the
> old "toolbox" multi-call binary and, in my understanding of these,
> they also output decimal. So I do believe there's precedence for
> approving my patch to change the single character to have the output
> match the busybox help's advertised "decimal" (and it's been advertised
> as that for many years).
>
> Further, I'd just like to reiterate that if it was an arbitrary by GNU
> to choose octal, maybe busybox could make a more informed decision; dd
> and a number of other important utilities use decimal only and it can be
> difficult to convert octal to decimal in a lot of shells, so decimal
> would be best for interoperability and usefulness.
>
> Once again, proper -t support would of course be ideal so we could have
> our GNU cake and eat it too, but would need a hand more familiar than
> mine with the source. Perhaps you could help, Tito?
>
> Thanks for your time and consideration everyone!
> Chris
>
>
Hi,
I could take a look at it if you are not in a hurry
because for the next 2 weeks I am in vacation and
I am a slow-coder due to lack of training.

Ciao,
Tito