RFC/RFA: strtod() magnitude problem

[Nick Clifton <nickc at redhat dot com>]

Hi Guys,

  The strtod() function appears to misbehave on targets where
  DOUBLE_IS_32_BITS is true.  For example:

    strtod ("123456789.10", &endptr)

  return will return a value or 1234567.125 rather than 123456792.0, ie
  two orders of magnitude too small.

  Unfortunately endptr will not be left pointing at "89.10", indicating
  that the remaining digits had not been consumed, but instead it will
  be point at the NUL following ".10".  Thus you cannot examine endptr
  to determine that the conversion has failed.

  The problem happens because the preprocessor constant DBL_DIG is set
  to 6, (for these small sized doubles targets), so only the first 7
  digits are considered for conversion.  Presumably the idea is that any
  value returned by strtod() must be able to be converted back into a
  similar string by atod().

  This problem is made worse by the fact that scanf() uses strtod() to
  perform ascii to floating point conversions so for example
  sscanf ("123456789.10") fails as well.

  I am not sure if the behaviour of strtod() is considered to be correct
  or not.  It certainly is counter-intuitive.  If the behaviour is
  correct then I still feel that scanf() should not suffer because of it
  and I have developed a tentative patch to work around the problem.
  (See attached).  But I would appreciate some guidance as to what the
  correct course of action should be.

Cheers
  Nick

Attachment: i3773242.patch.2
Description: Unix manual page