Extra zero byte converting mpz_t to a string

[Vincent Lefevre]

On 2015-04-18 10:15:19 +0200, Marc Glisse wrote:
> On Sat, 18 Apr 2015, Dmitry Antipov wrote:
> 
> >for some strange reason, an attached program outputs an unwanted
> >trailing zero byte for 6!, 14!, 24!, 29!, 31!, 33!, 40!, 52!, 60!,
> >65!, 66!, 71!, 79!, 81! and 96!-100! (full output is also attached).
> 
> I didn't look closely, but did you see the doc of mpz_sizeinbase?
> "The result will be either exact or 1 too big"

What matters is the doc of mpz_get_str, which says:

     Convert OP to a string of digits in base BASE. [...]

     If STR is `NULL', the result string is allocated using the current
     allocation function (*note Custom Allocation::).  The block will be
     `strlen(str)+1' bytes, that being exactly enough for the string and
     null-terminator.

     If STR is not `NULL', it should point to a block of storage large
     enough for the result, that being `mpz_sizeinbase (OP, BASE) + 2'.
     The two extra bytes are for a possible minus sign, and the
     null-terminator.

Here the result is a string, and a string stops at the *first* null
byte. If GMP writes a second null byte, then that's a bug.

-- 
Vincent Lefèvre <vincent at vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)