[patch, libgfortran][4.3 regression] PR32554 Bug in P formatting

[Jerry DeLisle]

Janne Blomqvist wrote:
> 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.
> 
> 
Incidentally, doing some additional experimentation with test cases I have been 
able to induce a segfault that this patch prevents.  I will add that to the test 
suite when I get a chance.

Jerry