[Toybox] A couple of minor fixes

[Paul Barker]

On Sun, 5 Jun 2016 14:17:24 -0500
Rob Landley <rob at landley.net> wrote:

> 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. :(
> 

In my experience, everyone violates posix!

Let's leave this out of toybox for now. Glibc "2.24" in OpenEmbedded is
a bit premature as upstream glibc doesn't seem to have released 2.24
yet. It's probably been updated due to the jump to gcc 6.1 breaking
things in older glibc releases. When it all settles down I'll give this
another look and see if the issue still remains.

Thanks,
Paul Barker