"bug" in gmp_scanf et al.?

[Vincent Lefevre]

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

  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)