gmp_snprintf tries to allocate 18 EB on long strings

[Marco Bodrato]

Ciao,

Il Mar, 23 Maggio 2017 8:34 pm, Vincent Lefevre ha scritto:
> Consider the following program:

>   r = gmp_snprintf (NULL, 0, "%2147483600s%100s%ln", "", "", &n);

> package), I get after 273 seconds:
>
> GNU MP: Cannot allocate memory (size=18446744071562067968)
>
> Wow! 18 EB! Actually this is close to 2^64. I suspect a conversion
> of a negative value to size_t as a consequence of an integer
> overflow.

There was an incorrect type in printf/snprntffuns.c, and was corrected
with https://gmplib.org/repo/gmp/rev/725745f3637f .

But the real problem is not that conversion... After the patch the example
by Vincent will take evenmore time to fail, but it will fail anyway, by
exhausting the allocable memory.

The current code is based on the following behaviour of vsnprintf, I copy
the comment:

/* glibc 2.0.x vsnprintf returns either -1 or size-1 for an overflow, with
   no indication how big the output would have been.  It's necessary to
   re-run to determine that size.

... so... if vsnprintf returns -1, it will be called again and again with
larger and larger buffers...
But if I understand correctly, current implementations of vsnprintf behave
differently. They return -1 only if vsnprintf will fail for any size of
the buffer, and return the needed size if the given one is too small.

I think we should change that code completely, calling the library
vsnprintf just once and trusting the result. It will break compatibility
with glibc 2.0.x, but we should not care of this any more, right?

Ĝis,
m

-- 
http://bodrato.it/papers/