[Toybox] A couple of minor fixes

[Paul Barker]

On Wed, 15 Jun 2016 09:40:29 -0500
Rob Landley <rob at landley.net> wrote:

> On 06/14/2016 02:54 AM, Paul Barker wrote:
> > On Mon, 13 Jun 2016 16:49:46 +0100
> > Paul Barker <paul at paulbarker.me.uk> wrote:
> > 
> >> On Mon, 13 Jun 2016 16:13:19 +0100
> >> Paul Barker <paul at paulbarker.me.uk> wrote:
> >>>
> >>> 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.
> >>>
> >>
> >> 	#include <limits.h>
> >> 	#include <stdio.h>
> >>
> >> 	int main(int argc, char *argv[])
> >> 	{
> >> 	    const char *str = "Hello, World!";
> >> 	    int trim[] = { INT_MAX, INT_MAX/2, INT_MAX/4,
> >> 		    INT_MAX/8, INT_MAX/16, INT_MAX/32, INT_MAX/64,
> >> 		    INT_MAX/128, INT_MAX/256, INT_MAX/512 };
> >> 	    int i;
> >>
> >> 	    for (i = 0; i < 10; i++) {
> >>         	printf("trim=%d : ", trim[i]);
> >> 	        printf("%.*s", trim[i], str);
> >>         	printf("\n");
> >> 	    }
> >>
> >> 	    return 0;
> >> 	}
> >>
> > 
> > I've now tried this on:
> > * Debian 8 (aka jessie or stable with glibc 2.19-18+deb8u4), x86_64
> > * Debian testing (aka stretch with glibc 2.22-11), x86_64.
> > * glibc 2.23 built from source on Debian testing, x86_64
> > * glibc built from source on Debian testing, x86_64
> 
> I've just been bisecting the glibc git repository to see where they
> introduced the bug. So far I've hit the fact that glibc-2.15 build
> breaks on current gcc:
> 
> In file included from <command-line>:0:0:
> ../misc/syslog.c: In function ‘__vsyslog_chk’:
> ../misc/syslog.c:123:30: error: inlining failed in call to
> always_inline ‘syslog’: function not inlinable
>  ldbl_strong_alias (__syslog, syslog)
> 
> And I'm bisecting between 2.15 and 2.16 to see where that got fixed.
> (Isn't it nice how often gcc "upgrades" fail to build existing
> packages?)
> 
> But I've been bisecting on a slow netbook during a series of meetings
> that run through Thursday (an engineering summit thing) so it's a slow
> background thing.
> 
> Interestingly, when the printf aborts it doesn't print anything
> _after_ the field in question either:
> 
>   printf("one %.*s three", INT_MAX, "two");
> 
> It doesn't print the "three" either. This is very, very clearly a
> glibc bug...
> 
> > I've also tried:
> > * OpenEmbedded master branch built for x86_64 (glibc post-2.23
> > release from git repository)
> > * OpenEmbedded krogoth branch (mid-2016 release, glibc 2.23)
> > * OpenEmbedded fido branch (mid-2015 release, glibc 2.21)
> > * OpenEmbedded daisy branch (mid-2014 release, glibc 2.19)
> 
> They use a glibc since the bug was introduced.
> 

Sorry, I'm not sure if we're looking at this in the same way. My
understanding is:

* Upstream glibc has a known issue
  (https://sourceware.org/bugzilla/show_bug.cgi?id=17829) and can't
  handle a precision of INT_MAX. This is seen when compiling natively

* Cross-compiling glibc with OpenEmbedded seems to lead to a worse form
  of the same issue, or an unrelated issue, meaning that a precision of
  INT_MAX/8 or higher also fail. I can't reproduce this failure on any
  native compilation of glibc I've tried.

In both cases I don't know the exact precision value at which failure
starts to occur.

Does this match what you've seen?

Thanks,
Paul Barker