Bug#644023: FTBFS on kfreebsd-i386
On Mon, Oct 03, 2011 at 03:59:50AM -0500, Jonathan Nieder wrote:
> Petr Salinger wrote:
>
> > It effectively test return code of
> >
> > fprintf (fp, "%2147483648d%2147483648d", 1, 1);
> >
> > The printf family returns int and should return number of written bytes.
> > It therefore cannot exceed MAX_INT.
> >
> > But the test tries to print twice entry with width MAX_INT+1.
> > I would understand the test with i.e. 2147483640
> > or six time 512 MB.
>
> Yeah, your suggested test would be a more precise test for the
> original bug[1].
>
> C99 (N1256 §7.19.6.1.4) only tells us that the field width is a
> "nonnegative decimal integer". It would be nice to clarify with the C
> working group whether a field width that doesn't fit into an "int"
> triggers undefined behavior or if the implementation is obligated to
> catch it.
>
> > On kfreebsd-amd64, it tries to
> > mmap(0,0xffffffff80001000,PROT_READ|PROT_WRITE,MAP_ANON|MAP_TYPE|MAP_PRIVATE,0xffffffff,0)
> > and fails.
>
> Sounds buggy. In fact, there are at least a couple of seemingly buggy
> aspects here.
>
> - read_int does not check for overflow
> - read_int returns "unsigned int", but "prec" and "width" are ints
> - the "for (; (size_t) nspecs_done < nspecs; ++nspecs_done)" loop
> does not check for overflow when deciding the initial work buffer
> size
> - the private __parse_one_spec API (and public parse_printf_format
> API) does not seem to include a way to indicate overflow
>
> Anyway, how about this patch? It implements your 6 times 512 MiB idea
> (well, 3 times 1 GiB because I'm lazy) and adds a new test for the
> related bug Robert found (which gets masked on Linux by malloc() not
> bothering to try to fulfill such huge requests --- maybe it would be
> possible to tweak it so it can fail on Linux, too).
Have you sent this patch upstream or do you plan do to do it?
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurelien@aurel32.net http://www.aurel32.net
Reply to: