[Bug 20804] Misbehavior of printf %e format.

[bugzilla-daemon@bugs.ecos.sourceware.org]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=20804

Bernd Edlinger <bernd.edlinger@hotmail.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bernd.edlinger@hotmail.de

--- Comment #10 from Bernd Edlinger <bernd.edlinger@hotmail.de> 2012-08-14 09:31:01 BST ---
(In reply to comment #9)
> Created an attachment (id=1895)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1895) [details]
> printf() zero-padding issue fix
> And may be just to expand a set of the arguments the cvt()? See the patch.
> Then this
>   printf("%g %- 30.18e\n", 3.14e-11, 3.14e-11);
>   printf("%g %- 30.18f\n", 3.14e-11, 3.14e-11);
> will output
>   3.14e-11  3.140000000000001000e-11
>   3.14e-11  0.000000000031400000
> Sergei

Hi Sergei,

no. The buffer "buf" has only place for 308 characters.
But fpprec can be any number. In my eyes the fpprec was invented
to protect against the buffer overrun here.
Probably there should be an output parameter, that indicates
where the exponent is, and that could be used to print
the mantissa, followed by fpprec zeros, followed by the exponent if any.

Another limitation that I do not really like is, that the %.18f
format does only print 15 digits, even if the number is very small.
but the double has 16 digits precision.

It is possible to fix that all together, but it is easy to introduce
new bugs too. And one of the most important things in a function like
sprintf, is that the stack usage should never increase what so ever.

If you want, we can open a new bug for the next iteration of this issue.

Bernd.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.