bug in gmp_fprintf?

[Vincent Lefevre]

On 2015-12-01 03:04:49 +0100, Leif Leonhardy wrote:
> Vincent Lefevre wrote:
> > On 2015-11-30 17:57:13 +0100, Torbjörn Granlund wrote:
> >> I should add that a big problem with gmp_*printf remains:
> >>
> >> When printing more than MAX_INT characters, the return value makes
> >> little sense.
> 
> The existing functions should IMHO never return a negative value upon
> success.

Printing more than MAX_INT characters can be regarded as some kind
of failure (distinct from write error).

> > C's printf has the same problem, in particular for GNU libc:
> > 
> >   https://sourceware.org/bugzilla/show_bug.cgi?id=5424
> > 
> > (a bug I reported 8 years ago). This has been solved by returning
> > a negative value and setting errno to EOVERFLOW so that it is not
> > confused with a real error. However this is less a problem in the
> > standard printf because it does not have to deal with high-precision
> > numbers, so that in practice, there are workarounds to avoid this
> > overflow if one really wants to.
> > 
> >> In order to fix that, we need to change the return value of these
> >> functions from int to e.g. long.  But that's a change which is not 100%
> >> source or binary compatible.
> > 
> > Alternatively, you could decide to return -1 in case of true error
> > and -2 in case of overflow on the return value (since you may not
> > want to use errno). To get the number of characters written, the
> > user could still use %n with an adequate length modifier, so that
> > there is no loss of information.
> 
> For backwards compatibility, I'd rather introduce /new/ functions

Note that my proposal would be backward compatible. Well, almost.
It is not clear what GMP should do if the C printf fails because of
the overflow on the return value (as mentioned above).

The GMP documentation also says:

  All the functions can return -1 if the C library `printf' variant in
  use returns -1, but this shouldn't normally occur.

I wonder what is meant by that. In case of failure, the printf() of
the C library returns a negative value, not necessarily -1.

> returning 'long' for the whole family of *printf()s, e.g. with an 'l'
> suffix (or probably prefix).

As you noticed, a "long" may not be sufficient. On 32-bit machines, it
is typically of the same size as an int: 32 bits.

> The original functions could become wrappers of those, returning just
> the number of characters written modulo MAX_INT (to be documented of
> course), and the usual [negative] value(s) in case of an error.  (I.e.,
> the return type would remain 'int' for these, such that "ordinary" code
> wouldn't need any changes.)

It is a very bad idea. For instance, if the function returns 17,
one wouldn't know whether the number of characters written is 17
or something much higher. So, the return value would not be truly
informative *even in common cases*. Sticking to MAX_INT would be
much better. Or a specific negative value as I suggested (-1 is
reserved for write errors in GMP, so that this is fine).

-- 
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)