[patch, libgfortran][4.3 regression] PR32554 Bug in P formatting
Janne Blomqvist
blomqvist.janne@gmail.com
Sun Jul 1 12:53:00 GMT 2007
Jerry DeLisle wrote:
> :ADDPATCH fortran:
>
> Hi all,
>
> The initial problem here is that gfortran was truncating by one with
> snprintf and overflowing the buffer by one with sprintf. Surprising we
> were not getting an error before enabling snprintf. Using snprintf
> uncovered this latent bug.
>
> Investigating further I found that the problem could be avoided by
> adjusting the calculation of the the number of digits, ndigits. I
> simply reduced this by one. However, examining the buffer after the
> calls to snprintf showed that the width was varying because the number
> of exponent digits, edigits, varied.
>
> Exploring this, I tried fixing the size of edigits to see what happens.
> I discovered that edigits does not need to be calculated at all. If it
> is set to the largest expected size (4) snprintf (and sprintf)
> conveniently pads blanks at the end anyway. (The exponent is read back
> in downstream by atoi)
>
> The result is seriously simplified code which should yield better
> performance.
>
> Regression tested on x86-64-pc-Gnu/Linux.
>
> Also NIST tested.
>
> NOTE: I tested with sprintf and snprintf on my system by commenting out
> the conditional compiles to make sure both work OK.
>
> I would prefer testing on other platforms such as Darwin. I will test
> on freebsd tonight.
>
> OK for trunk?
Ok.
> We should probably back port this to 4.2 (though it does not
> manifest) since it is a buffer overrun issue.
Yes. Though I suggest you wait a week or two, in case some obscure bug
pops up due to this fix.
--
Janne Blomqvist
More information about the Fortran
mailing list