"bug" in gmp_scanf et al.?

Vincent Lefevre vincent at vinc17.org
Thu Mar 11 02:52:13 CET 2010

On 2010-03-09 15:39:28 -0800, Ronald Bruck wrote:
> gmp_scanf, gmp_fscanf, and gmp_sscanf all consider a real number of
> the form 1.23e to be malformed. I'm inclined to agree; but that's
> not what seems to be the C standard. At least I deduce that from
> this program, compiled with icc. (I haven't c checked to see if the
> compiler's behavior is correct.)

1.23e is malformed, but 1.23 is well-formed. I think this is what
you see with sscanf. Note that scanf and fscanf can show a different
behavior because:

[ISO/IEC 9899:TC3 - WG14/N1256]

  An input item is read from the stream, unless the specification
  includes an n specifier. An input item is defined as the longest
  sequence of input characters which does not exceed any specified
  field width and which is, or is a prefix of, a matching input

  251) fscanf pushes back at most one input character onto the input
       stream. Therefore, some sequences that are acceptable to
       strtod, strtol, etc., are unacceptable to fscanf.

So, on "1.23ez", strtod will consider 1.23, but fscanf must read
up to the 'z' character, push it back, and since it cannot push 'e'
back too, it will fail. (Not tested.)

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

More information about the gmp-bugs mailing list