This is the mail archive of the
newlib@sources.redhat.com
mailing list for the newlib project.
Re: Problem with floating point display printf()
- From: Jeff Johnston <jjohnstn at redhat dot com>
- To: Bernhard Walle <bwalle at fh-landshut dot de>
- Cc: newlib at sources dot redhat dot com
- Date: Mon, 08 Nov 2004 19:59:11 -0500
- Subject: Re: Problem with floating point display printf()
- References: <20041108235612.GA6978@mail1.bwalle.de>
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.