[Toybox] A couple of minor fixes

[Paul Barker]

On Mon, 13 Jun 2016 07:49:06 -0700
enh <enh at google.com> wrote:

> On Mon, Jun 13, 2016 at 12:12 AM, Mike Moreton
> <Mike.Moreton at frontier-silicon.com> wrote:
> >> have you reported this bug to your supplier?
> >>
> >> have you experimented to work out what they largest value they
> >> _can_ cope with is? does your version work with INT_MAX? (maybe
> >> your supplier backported the "fix" that's introduced a new bug?)
> >
> > With the greatest of respect (genuinely), I think this is slightly
> > missing the point - there are many ways I can fix this problem for
> > us, so it's no great problem for us.
> 
> knowing what values this particular broken glibc can cope with (since
> it's apparently different to the two other broken glibcs we've already
> seen --- the existing hack was chosen to work on both of those, plus
> non-broken c libraries) is a prerequisite to working around the bug...
> 

Not really - this is why I chose the following construct:

	if (trim) xprintf("%.*s%c", trim, line, TT.outdelim);
	else xprintf("%s%c", line, TT.outdelim);

If trim is passed we can assume it's a sensible value and the
underlying libc can handle it. If trim is not passed we assume nothing.

Personally I think the above construct makes more sense than setting an
arbitrarily-high-but-not-infinite default trim value if no trim value
is given anyway. I'd prefer it to the original even in the absense of
the glibc bug - but that's just my opinion.

I still agree that this should be fixed in glibc if possible though.
I'll build a test app later and see what happens for different trim
values (INT_MAX, INT_MAX/2, INT_MAX/4, etc) with glibc in an
OpenEmbedded build.

Thanks,
Paul Barker