Re: [Patch, libgfortran] PR29936 Missed constraint on RECL=specifier in unformatted sequential WRITE

[Jerry DeLisle <jvdelisle at verizon dot net>]

Thomas Koenig wrote:
> On Tue, Nov 21, 2006 at 11:25:48PM -0800, Jerry DeLisle wrote:
>
> Hi Jerry,
>
> > The attached patch adds a flag to the units flags structure to identify if 
> > a RECL= was specified in the OPEN statement.  This flag is then initialized 
> > in new_unit and is used in us_write to not set the current_unit->recl to 
> > max_record.
>  
> This will compilcate my large-record patch somewhat. I am currently
> using current_unit->recl to keep track of the subrecord length,
> so I will need to introduce additonal bookkeeping (and separate
> the codepaths for unformatted direct and unformatted sequential
> on reading, which might not be a bad idea).

Can you use last_record of strm_pos to track subrecord length?

Or you can add a new variable there in gfc_unit fairly safely since the unit 
structure is allocated at run time and should be fairly safe compatibility wise.
> Re-setting the record length in us_write doesn't do anything useful
> at the moment as far as I have been able to determine.

I don't understand this statement.  The patch I applied is not resetting the 
record length, it is allowing the RECL= passed in the OPEN to go unchanged.  It 
was being set to maxrec to allow the record length to default to the size of the 
output list.  If you mean that it does not have to be done in us_write and could 
be done somewhere else, I agree that it could be.
> Of course, if we can't use RECL= on in an OPEN statement to set
> the maximum subrecord size, then we are in trouble as far as a
> test case for subrecord sizes is concerned.  We can hardly write
> out a 2GB record each time in the testsuite, so we need some other
> way to specify a shorter maximum record length in the testsuite.

We do not necessarily need a test case for a huge record in the test suite.  I 
had to remove a large file I/O test case I had because it caused some systems to 
hang if they did not have enough free disk space to execute it.  I think this is 
another case like that where we test outside of the test suite and call it good. 
 I would rather not add another option, but I am not objecting.

Why not compute the subrecord size from the record size passed in RECL= ?  Maybe 
there is an optimal subrecord size for performance.

> The only way would be a new option, such as -fsubrecord-maxlength=
> which we could then use in the test suite (and which would be
> largely useless for anything else).
>
> > I will commit to trunk as simple and obvious along with a suitable test 
> > case.
>
> I'd rather if you didn't.  I agree that this is a bug that should
> be fixed (and you can assign the PR to me if you want to),
> although I'd tend to issue a warning by default (be liberal
> in what you accept, conservative in what you send :-)

Too late, I did it last night. :)

Jerry