[Bug 20804] Misbehavior of printf %e format.

[Bug 20804] Misbehavior of printf %e format.

[bugzilla-daemon]

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

Sergei Gavrikov <sergei.gavrikov@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|Other                       |C library
            Version|1.3.1                       |CVS
         AssignedTo|backlog@bugs.ecos.sourcewar |unassigned@bugs.ecos.source
                   |e.org                       |ware.org

--- Comment #3 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2012-08-08 19:50:35 BST ---
The bug still exists and it can be reproduced. See, bug #1001490.

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

[Bug 20804] Misbehavior of printf %e format.

[bugzilla-daemon]

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

--- Comment #4 from Bernd Edlinger <bernd.edlinger@hotmail.de> 2012-08-09 11:58:04 BST ---
Created an attachment (id=1883)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1883)
cumulative patch to fix several defects in the %e, %f and %g formats.

see the discussion on [Bug #1001490], and [Bug #1001628]

Note: This patch fixes the %.18e format at least partially, that means,
the 3 extra zeroes are no longer appended to the exponent, but the resulting
output is like %.15e.

Adding an arbitrary number of zeroes between the fractional part and the
exponent, without overflowing any buffers, remains to be done.

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

[Bug 20804] Misbehavior of printf %e format.

[bugzilla-daemon]

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

--- Comment #6 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2012-08-12 19:06:52 BST ---
I plan to apply the Bernd's patch in these days. If anyone has any objections,
please, let me know.

Sergei

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

[Bug 20804] Misbehavior of printf %e format.

[bugzilla-daemon]

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

Jonathan Larmour <jifl@ecoscentric.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jifl@ecoscentric.com

--- Comment #7 from Jonathan Larmour <jifl@ecoscentric.com> 2012-08-13 21:57:40 BST ---
Yes I object, looking at the patch, I don't think it's right. I don't see the
reason for this:

-                                if ((ch != 'g' && ch != 'G') || (flags&ALT))
+                                if (ch == 'f')

The precision (e.g. 18 in "%.18f") is defined as the number of digits to appear
after the radix character for e, E, and f conversions, or the maximum number of
significant digits for g and G conversions. I don't see how the above can fit
into that, nor do I have confidence that the ALT flag ('#') is correctly
handled.

And Bernd seems to have doubts too - he says in bug 1001490 it's only an
interim solution. I don't want to be swapping one set of problems for a
different but now less known set of problems.

Unfortunately I don't have the time to look at this at the moment as I'm
leaving on holiday soon and have to finish work things off. But I'd want to see
confidence that the changes made are correct before committing.

Jifl

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

[Bug 20804] Misbehavior of printf %e format.

[bugzilla-daemon]

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

--- Comment #8 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2012-08-14 07:50:29 BST ---
Jifl, thank you for expertise and time. I agree with your points about other
float formats. Bernd, excuse my haste. I'm sorry about this mess. I withdraw
the claim.

Sergei

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

[Bug 20804] Misbehavior of printf %e format.

[bugzilla-daemon]

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

--- Comment #9 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2012-08-14 08:41:03 BST ---
Created an attachment (id=1895)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1895)
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

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

[Bug 20804] Misbehavior of printf %e format.

[bugzilla-daemon]

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.

[Bug 20804] Misbehavior of printf %e format.

[bugzilla-daemon]

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

--- Comment #11 from Bernd Edlinger <bernd.edlinger@hotmail.de> 2012-08-14 09:49:47 BST ---
(In reply to comment #7)
> Yes I object, looking at the patch, I don't think it's right. I don't see the
> reason for this:
> -                                if ((ch != 'g' && ch != 'G') || (flags&ALT))
> +                                if (ch == 'f')
> The precision (e.g. 18 in "%.18f") is defined as the number of digits to appear
> after the radix character for e, E, and f conversions, or the maximum number of
> significant digits for g and G conversions. I don't see how the above can fit
> into that, nor do I have confidence that the ALT flag ('#') is correctly
> handled.
Hello,

let me explain this.

For the %f and %g format the ALT means we always have a "." output.
"%#.0f", 3.14  would print "3." here we could add zeros if we want.
while "%.0f", 3.14 would pritn "3", adding zeroes here would be bad..

Why I dont care about the ALT here, is because the precision is > 15,
therefore %.15f and %#.15f produce the same output. always.
and it is safe to append zeros, except in the case where the number
is "NAN" or "INF", but appending 3 zeros to NAN is only a fauxpas.

But to %.15g and %#.15g the ALT flag makes a difference.
if the number has no digits after the "." then
"%.15g", 3.0 prints "3" and adding 3 zeros here would be a bad idea.
while "%#.15g" prints "3.00000000000000", so adding zeros is OK.
that is what was the assumption behind "if ((ch != 'g' && ch != 'G') ||
(flags&ALT))"

But they forgot all about the %e format, and that the %g format defaults
to %e if the number is very small or very large.

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.

[Bug 20804] Misbehavior of printf %e format.

[bugzilla-daemon]

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

Sergei Gavrikov <sergei.gavrikov@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1895|0                           |1
        is obsolete|                            |

--- Comment #12 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2012-08-14 10:14:49 BST ---
(From update of attachment 1895)
Ups. Forget it. See Bernd's comment #10.

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

[Bug 20804] Misbehavior of printf %e format.

[bugzilla-daemon]

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

--- Comment #13 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2012-08-14 11:47:35 BST ---
(In reply to comment #10)

Hi Bernd,

[snip]
> Hi Sergei,
> 
> no. The buffer "buf" has only place for 308 characters.

Ah! Yes, that's my fault which does introduce a real BUG. I hope that comment
#12 fixed it :-)

[snip]

> It is possible to fix that all together, but it is easy to introduce
> new bugs too.
  ^^^^^^^^^^^^^

It's hard to argue. It seems we need in more extensive *printf* test suite for
floating point formats.

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

Agreed. IMHO, this thread is good for %e issue and its friends. However, there
are a few things we would fix in vfnprintf.cxx according your ChangeLog record.
It seems you right those fixes can be submitted separately.

Thanks,
Sergei

> 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.

[Bug 20804] Misbehavior of printf %e format.

[bugzilla-daemon]

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

--- Comment #14 from Bernd Edlinger <bernd.edlinger@hotmail.de> 2012-08-14 13:34:08 BST ---
(In reply to comment #13)
Hi Sergei,

> > It is possible to fix that all together, but it is easy to introduce
> > new bugs too.
>   ^^^^^^^^^^^^^
> It's hard to argue. It seems we need in more extensive *printf* test suite for
> floating point formats.

definitely.

> > If you want, we can open a new bug for the next iteration of this issue.
> Agreed. IMHO, this thread is good for %e issue and its friends. However, there
> are a few things we would fix in vfnprintf.cxx according your ChangeLog record.
> It seems you right those fixes can be submitted separately.
> Thanks,
> Sergei


I am honestly convinced, that this patch does only improve the situation.
Especially the possible buffer overflow, and the stack usage can be
quite critical issues in eCos.

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.

[Bug 20804] Misbehavior of printf %e format.

[bugzilla-daemon]

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

Sergei Gavrikov <sergei.gavrikov@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|Other                       |C library
            Version|1.3.1                       |CVS
         AssignedTo|backlog@bugs.ecos.sourcewar |unassigned@bugs.ecos.source
                   |e.org                       |ware.org

--- Comment #3 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2012-08-08 19:50:35 BST ---
The bug still exists and it can be reproduced. See, bug #1001490.

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

[Bug 20804] Misbehavior of printf %e format.

[bugzilla-daemon]

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

--- Comment #4 from Bernd Edlinger <bernd.edlinger@hotmail.de> 2012-08-09 11:58:04 BST ---
Created an attachment (id=1883)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1883)
cumulative patch to fix several defects in the %e, %f and %g formats.

see the discussion on [Bug #1001490], and [Bug #1001628]

Note: This patch fixes the %.18e format at least partially, that means,
the 3 extra zeroes are no longer appended to the exponent, but the resulting
output is like %.15e.

Adding an arbitrary number of zeroes between the fractional part and the
exponent, without overflowing any buffers, remains to be done.

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

[Bug 20804] Misbehavior of printf %e format.

[bugzilla-daemon]

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

--- Comment #6 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2012-08-12 19:06:52 BST ---
I plan to apply the Bernd's patch in these days. If anyone has any objections,
please, let me know.

Sergei

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

[Bug 20804] Misbehavior of printf %e format.

[bugzilla-daemon]

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

Jonathan Larmour <jifl@ecoscentric.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jifl@ecoscentric.com

--- Comment #7 from Jonathan Larmour <jifl@ecoscentric.com> 2012-08-13 21:57:40 BST ---
Yes I object, looking at the patch, I don't think it's right. I don't see the
reason for this:

-                                if ((ch != 'g' && ch != 'G') || (flags&ALT))
+                                if (ch == 'f')

The precision (e.g. 18 in "%.18f") is defined as the number of digits to appear
after the radix character for e, E, and f conversions, or the maximum number of
significant digits for g and G conversions. I don't see how the above can fit
into that, nor do I have confidence that the ALT flag ('#') is correctly
handled.

And Bernd seems to have doubts too - he says in bug 1001490 it's only an
interim solution. I don't want to be swapping one set of problems for a
different but now less known set of problems.

Unfortunately I don't have the time to look at this at the moment as I'm
leaving on holiday soon and have to finish work things off. But I'd want to see
confidence that the changes made are correct before committing.

Jifl

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

[Bug 20804] Misbehavior of printf %e format.

[bugzilla-daemon]

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

--- Comment #8 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2012-08-14 07:50:29 BST ---
Jifl, thank you for expertise and time. I agree with your points about other
float formats. Bernd, excuse my haste. I'm sorry about this mess. I withdraw
the claim.

Sergei

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

[Bug 20804] Misbehavior of printf %e format.

[bugzilla-daemon]

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

--- Comment #9 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2012-08-14 08:41:03 BST ---
Created an attachment (id=1895)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1895)
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

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

[Bug 20804] Misbehavior of printf %e format.

[bugzilla-daemon]

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 on the CC list for the bug.

[Bug 20804] Misbehavior of printf %e format.

[bugzilla-daemon]

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

--- Comment #11 from Bernd Edlinger <bernd.edlinger@hotmail.de> 2012-08-14 09:49:47 BST ---
(In reply to comment #7)
> Yes I object, looking at the patch, I don't think it's right. I don't see the
> reason for this:
> -                                if ((ch != 'g' && ch != 'G') || (flags&ALT))
> +                                if (ch == 'f')
> The precision (e.g. 18 in "%.18f") is defined as the number of digits to appear
> after the radix character for e, E, and f conversions, or the maximum number of
> significant digits for g and G conversions. I don't see how the above can fit
> into that, nor do I have confidence that the ALT flag ('#') is correctly
> handled.
Hello,

let me explain this.

For the %f and %g format the ALT means we always have a "." output.
"%#.0f", 3.14  would print "3." here we could add zeros if we want.
while "%.0f", 3.14 would pritn "3", adding zeroes here would be bad..

Why I dont care about the ALT here, is because the precision is > 15,
therefore %.15f and %#.15f produce the same output. always.
and it is safe to append zeros, except in the case where the number
is "NAN" or "INF", but appending 3 zeros to NAN is only a fauxpas.

But to %.15g and %#.15g the ALT flag makes a difference.
if the number has no digits after the "." then
"%.15g", 3.0 prints "3" and adding 3 zeros here would be a bad idea.
while "%#.15g" prints "3.00000000000000", so adding zeros is OK.
that is what was the assumption behind "if ((ch != 'g' && ch != 'G') ||
(flags&ALT))"

But they forgot all about the %e format, and that the %g format defaults
to %e if the number is very small or very large.

Bernd.

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

[Bug 20804] Misbehavior of printf %e format.

[bugzilla-daemon]

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

Sergei Gavrikov <sergei.gavrikov@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1895|0                           |1
        is obsolete|                            |

--- Comment #12 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2012-08-14 10:14:49 BST ---
(From update of attachment 1895)
Ups. Forget it. See Bernd's comment #10.

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

[Bug 20804] Misbehavior of printf %e format.

[bugzilla-daemon]

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

--- Comment #13 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2012-08-14 11:47:35 BST ---
(In reply to comment #10)

Hi Bernd,

[snip]
> Hi Sergei,
> 
> no. The buffer "buf" has only place for 308 characters.

Ah! Yes, that's my fault which does introduce a real BUG. I hope that comment
#12 fixed it :-)

[snip]

> It is possible to fix that all together, but it is easy to introduce
> new bugs too.
  ^^^^^^^^^^^^^

It's hard to argue. It seems we need in more extensive *printf* test suite for
floating point formats.

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

Agreed. IMHO, this thread is good for %e issue and its friends. However, there
are a few things we would fix in vfnprintf.cxx according your ChangeLog record.
It seems you right those fixes can be submitted separately.

Thanks,
Sergei

> Bernd.

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

[Bug 20804] Misbehavior of printf %e format.

[bugzilla-daemon]

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

--- Comment #14 from Bernd Edlinger <bernd.edlinger@hotmail.de> 2012-08-14 13:34:08 BST ---
(In reply to comment #13)
Hi Sergei,

> > It is possible to fix that all together, but it is easy to introduce
> > new bugs too.
>   ^^^^^^^^^^^^^
> It's hard to argue. It seems we need in more extensive *printf* test suite for
> floating point formats.

definitely.

> > If you want, we can open a new bug for the next iteration of this issue.
> Agreed. IMHO, this thread is good for %e issue and its friends. However, there
> are a few things we would fix in vfnprintf.cxx according your ChangeLog record.
> It seems you right those fixes can be submitted separately.
> Thanks,
> Sergei


I am honestly convinced, that this patch does only improve the situation.
Especially the possible buffer overflow, and the stack usage can be
quite critical issues in eCos.

Bernd.

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

[Bug 20804] Misbehavior of printf %e format.

[bugzilla-daemon]

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

Sergei Gavrikov <sergei.gavrikov@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|Other                       |C library
            Version|1.3.1                       |CVS
         AssignedTo|backlog@bugs.ecos.sourcewar |unassigned@bugs.ecos.source
                   |e.org                       |ware.org

--- Comment #3 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2012-08-08 19:50:35 BST ---
The bug still exists and it can be reproduced. See, bug #1001490.

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