[patch, fortran] PR31201 Too large unit number generates wrong code

Jerry DeLisle jvdelisle@verizon.net
Wed Apr 4 04:53:00 GMT 2007


:ADDPATCH fortran:

The attached patch fixes this issue by first changing the type of the unit 
number to GFC_IO_INT which is an 8 byte value (or 4 bytes if a system does not 
support 8).  The size of the unit parameters in the front end are appropriately 
adjusted.

I took this approach because the f95 standard defines the unit number as a 
scaler_int_expr.  Therefore it is legal to use any integer expression that may 
not have a value determined except at runtime.

Then I defined MAX_UNIT to be 99999.  I figured this is enough.  Regardless, it 
should be set to a value that fits in a positive 32 bit integer.  Whatever is 
settled on needs to be documented in the manual.

The size of unit is adjusted accordingly in st_parameter_common which is used by 
OPEN, CLOSE, READ, WRITE, INQUIRE, BACKSPACE, REWIND, and ENDFILE.

A new function, check_unit (st_parameter_common *), is added to the library that 
checks the unit number and generates an error if it is out of the allowed range, 
0 to 99999.

Check_unit is then called in each of the affected statements.

I suspect this modifies the ABI since the size of st_parameter_common is changed.

iomsg_1.f90 in the test suite had to be adjusted for the error message which is 
now generic across all statements.

RFC Also note:  I found an unfreed memory block from libgfortran/runtime/main.c 
with valgrind while testing.  I added a free in "cleanup" which appears to have 
eliminated this, however, it causes many failures in the testsuite.  I am not 
sure if it was specific to the test case I had or not.  I left that change out. 
  I have not seen this in previous test I have done.  I will have to revert this 
patch and see if it is still there.  I don't see how it would be related to this 
patch.

Regression tested on x86-64-Gnu/Linux.  Valgrind tested on runtime executable of 
the test case.

OK for trunk?  This should not go to 4.2.

I will dejanuize the test case and expand it some.

Regards,

Jerry

2007-04-03  Jerry DeLisle  <jvdelisle@gcc.gnu.org>

	PR libgfortran/31201
	* libgfortran.h: Define MAX_UNIT.
	(struct st_parameter_common) Change unit type to GFC_IO_INT.
	* io/io.h (struct st_parameter_filepos): Update type of *number.
	(struct gfc_unit): Update type of *unit_number.
	(check_unit):  Add function prototype for this new function.
	* io/unit.c (check_unit): New function
	* io/file_pos.c (st_backspace, st_endfile, st_rewind, st_flush): Use new
	function, check_unit.
	* io/open.c (st_open): Use new function.
	* io/close.c (st_close): Use new function.
	* io/inquire.c (inquire_via_unit): Use MAX_UNIT.
	* io/transfer.c (data_transfer_init): Delete old code not needed.
	(st_read): Use new function. (st_write): Use new function.

2007-04-03  Jerry DeLisle  <jvdelisle@gcc.gnu.org>

	PR fortran/31201
	* ioparm.def: Modify "unit" to kind 8.

2007-04-03  Jerry DeLisle  <jvdelisle@gcc.gnu.org>

	PR libgfortran/31201
	* gfortran.dg/iomsg_1.f90: Update test.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: pr31201.f
Type: text/x-fortran
Size: 368 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20070404/9f71d950/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: iomsg_1.f90
Type: text/x-fortran
Size: 791 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20070404/9f71d950/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pr31201.diff
Type: text/x-patch
Size: 9139 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20070404/9f71d950/attachment-0002.bin>


More information about the Fortran mailing list