[Toybox] A couple of minor fixes

[Rob Landley]

On 06/05/2016 01:34 PM, Paul Barker wrote:
> On Sun, 5 Jun 2016 12:41:43 -0500
> Rob Landley <rob at landley.net> wrote:
> 
>> On 06/05/2016 06:45 AM, Paul Barker wrote:
>>> * grep didn't print any output due to printf choking on a field
>>> width of INT_MAX/2.
>>
>> Wait, what? We cut it _down_ to INT_MAX/2 because glibc's printf
>> started choking on a field with of INT_MAX sometime after Ubuntu
>> 12.04 (where it worked just fine):
>>
>> commit 93e27d0d4723d57082463c4d70e6443060a8732b
>> Author: Rob Landley <rob at landley.net>
>> Date:   Wed Feb 10 16:23:31 2016 -0600
>>
>>     Although printf("%.*s", INT_MAX, s) works fine on ubuntu 12.04,
>>     it broke since.
>>
>> Now it can't handle the _smaller_ value? What libc version has this
>> new bug?
>>
> 
> I saw this in the git history and did start to wonder what keeps
> changing. I haven't really had much time to look into it though, I've
> just gone for a fix which never assumes that printf can handle a
> particular large field width.
> 
> OpenEmbedded master branch is currently using glibc 2.24 plus a bunch
> of patches. I'm building for a 32-bit system if that makes a difference.

Hmmm. It shouldn't, but not knowing what the bug is...?

This works on musl, uclibc, bionic, and older versions of glibc. That
pretty clearly pegs it as a glibc bug, and I'm reluctant to merge bug
workarounds for other packages.

I caved on the INT_MAX thing because it was a corner case, being
_that_close_ triggering an integer overflow was understandable, although
http://pubs.opengroup.org/onlinepubs/9699919799/functions/printf.html
says "A negative precision is taken as if the precision were omitted."
so even overflow of a signed value shouldn't screw stuff up here.
(Modulo stupid compiler "optimizations" breaking stuff.)

But if they can't handle INT_MAX/2, it sounds like they're violating
posix. That's a bug in glibc printf, not in my code. :(

> Thanks,
> Paul Barker

Rob