bug in gmp_fprintf?

[Leif Leonhardy]

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.


> 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
returning 'long' for the whole family of *printf()s, e.g. with an 'l'
suffix (or probably prefix).

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


(A subtle issue is still that 'long's aren't necessarily wider than
'int's, on typical 32-bit machines at least.)


-leif