This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: sprintf bugs with floating point and field specifiers?


Apologies! This test-case works fine for all the 3 cases with newlib-1.14.0.

I had a problem with a debugger command, which was not reloading my
ELF files between different compilations and I was re-running stale
executables.

Again, apologies for any confusion and thanks for all the help.

Matt

It was due to a problem with the debugger I was using.

On 9/8/06, Matt Lee <reachmatt.lee@gmail.com> wrote:
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.
>
>
>



--
thanks,
Matt


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]