Re: Problem with floating point display printf()

[Jeff Johnston <jjohnstn at redhat dot com>]

Bernhard Walle wrote:
> Hello,
>
> we use newlib on a MVME162 board with following configuration:
>
>     ./configure                         \
>         --target=m68k-elf               \
>         --program-prefix=m68k-elf-      \
>         --prefix=%{prefix}              \
>         --mandir=%{prefix}/share/man    \
>         --infodir=%{prefix}/share/info  \
>         --with-gnu-as                   \
>         --with-gnu-ld                   \
>         --enable-m68040
>
> The newlib version ist 1.12.0. The problem is that the decimal
> separator printed out with printf() is a random character unless we 
> call setlocale(LC_ALL, "C"). In my opinion this call should not be
> necessary.
>
> Kind regards,
>  Bernhard Walle

Bernhard,

  You are right that this shouldn't be happening.  Right now, the vfprintf.c 
code initializes the decimal separator to: localeconv()->decimal_point.  At 
present, localeconv() is hard-wired in newlib to point to &lconv which has a "." 
as the decimal separator.  The locale setting is meaningless.

From libc/locale/locale.c:

static _CONST struct lconv lconv =
{
  ".", "", "", "", "", "", "", "", "", "",
  CHAR_MAX, CHAR_MAX, CHAR_MAX, CHAR_MAX,
  CHAR_MAX, CHAR_MAX, CHAR_MAX, CHAR_MAX,
};

struct lconv *
_DEFUN(_localeconv_r, (data),
      struct _reent *data)
{
  return (struct lconv *) &lconv;
}

struct lconv *
_DEFUN_VOID(localeconv)
{
  return _localeconv_r (_REENT);
}

  Have you by any chance linked some other code somewhere?

  You should be able to test out under gdb that _vfprintf_r is calling 
localeconv() and that it is returning &lconv.

-- Jeff J.