[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