Re: [patch, libgfortran] Fix PR20257 End of record occurs when writing large arrays

[Jerry DeLisle <jvdelisle at verizon dot net>]

Brooks Moses wrote:
> FX Coudert wrote:
>
> > > We can reserve a few numbers for internal use - say, 2**31-1024 to 
> > > 2**31-1
> > > (the maximum positive GFC_INTEGER_4).  Attempts to open or otherwise use
> > > these should be an error, and inquire(exist) could return false, like
> > > negative numbers right now.
> >
> >
> > It might be a stupid suggestion (I don't have access to the code right 
> > now): why not use negative numbers?
>
>
> This seems like a very parallel case to user-defined derived-type I/O 
> procedures in Fortran 2003 (Section 9.5.3.7.2).  When such a procedure 
> is called for an internal file, "the UNIT argument shall have a 
> processor-dependent negative value".  (Note that this is the argument 
> that's passed by the processor to a user-defined subroutine, not the 
> other way around.)  So, once we implement that, we'll have to be doing 
> something involving identifying internal files by a negative unit number 
> anyway; might as well go ahead and do it now and make things consistent.
>
> ...
>
> Also, on a slightly related note (but I wrote this all before I realized 
> that the above case existed, so I might as well send it), we'll 
> eventually be connecting negative unit numbers to external files as 
> well.  There's an addition to the Fortran syntax for the standard after 
> f2003 that would allow for automatic allocation of unit numbers, and in 
> particular uses negative unit numbers for this allocation (to avoid any 
> possible conflicts with unit numbers in existing code).  More info in 
> this thread on comp.lang.fortran, and in the actual J3 work item:
>
> http://groups.google.com/group/comp.lang.fortran/browse_frm/thread/5c2aebdfc608c23d/ 
>
> http://j3-fortran.org/doc/year/06/06-138r2.txt
>
> How this affects the present case, in my opinion, is that gfortran will 
> eventually need to support negative unit numbers whether it currently 
> does or not, so there's no harm in crossing that bridge now.  Also, it 
> appears to me that there should be no future problem with blocking out 
> chunks of negative unit numbers for internal use, as they will only be 
> automatically assigned rather than user-assigned so we don't have to 
> worry about conflicts with user code even in future Fortran versions.
>
> - Brooks
My first attempt at this was to use a negative number for unit.  IIRC there was 
specific existing code that generates an error for negative unit numbers.  I 
will explore this a bit and come back with something.

Thanks for all the comments!

Regards,

Jerry