This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]