Re: sprintf bugs with floating point and field specifiers?

["Matt Lee" <reachmatt dot lee at gmail dot com>]

Hi Jeff,

Thanks for the patch. It indeed fixes part of the problem. This is my
new output,

+00
00000
+0000

Sorry that I didn't notice that it fixed the latter two cases (I was
insisting that I was getting same results on newlib-1.14.0).

So basically the above output is what I get with CVS HEAD and newlib-1.14.0.

If you have any more ideas about the first case, please let me know.
The comment just above the code in the attached patch seems to
indicate that it should handle the "0.X" case, but it actually fixed
the other cases.

thanks,

On 9/6/06, Jeff Johnston <jjohnstn@redhat.com> wrote:
> Dave Korn wrote:
> > On 06 September 2006 00:10, Matt Lee wrote:
> >
> >
> >>I am seeing some bugs with Newlib sprintf and floating point format
> >>specifiers. Specifically, the following bits of code work incorrectly,
> >
> >
> >>Output On Xilinx PowerPC 405 platform,
> >>
> >>+00
> >>0000
> >>+000
> >>
> >>while on desktop Linux I get,
> >>
> >>+00.0
> >>00000
> >>+0000
> >
> >
> >   On current cygwin, I get
> >
> > dk@rainbow /artimi/software> ./foo.exe
> > +00.0
> > 00000
> > +0000
> > dk@rainbow /artimi/software>
> >
>
> The same correct results occur for x86-linux (which uses _ldtoa_r) and
> mn10300-elf which uses _dtoa_r.
>
> I should point out that if your configuration is powerpc-*spe* or
> powerpc-*altivec*, then powerpc supplies its own copy of vfprintf.c
> found in libc/machine/powerpc which has not been kept in lock-step with
> changes in the regular version.  I looked at a diff between the powerpc
> version and the regular vfprintf.c and could only find one diff that
> might be relevant to this situation.  I have attached a patch to this
> note for you to try out if your configuration is relevant (the patch is
> to be applied to libc/machine/powerpc/vfprintf.c).
>
> My only other thought is that perhaps your 1.14.0 attempt somehow got
> the 1.9.0 version of the code.  That is easy enough for you to verify
> via debugging.
>
> -- Jeff J.