Extra zero byte converting mpz_t to a string
vincent at vinc17.net
Mon Apr 20 06:49:38 UTC 2015
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
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
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)
More information about the gmp-bugs