Help!! end-of-file during read, unit 1...
in [Fortran]
|
Prev: GCC/gfortran 4.5.0 release
Next: linking not done
From: robert.corbett on 16 Apr 2010 22:12 On Apr 16, 11:02 am, nos...(a)see.signature (Richard Maine) wrote: > J. Clarke <jclarke.use...(a)cox.net> wrote: > > ...that then points to another bug in the sample > > given. It uses "c" in the first line for comments but several lines > > start in the first six columns, so it adheres neither convention. > > I was about to say that at a quick glance I didn't notice any such. In > fact, I didn't see them even at a second glance when counting more > carefully. But that appears to be because I must have been looking with > something that converted tabs to blanks. (Almost embarassed myself as a > result - wouldn't have been the first time). When I threw it at a > compiler to see if it noticed something I was missing... it did so. Yes, > the code appears to use a tab source form, which, as you correctly note, > is neither standard conforming fixed nor free source form. The presence of tabs in the representation of a program on a storage medium does not preclude the program from being standard conforming for a given implementation. Section 1.4 of the Fortran 2003 standard states This standard does not specify . . . (3) The method of transcription of programs or their input or output data to or from a storage medium, For example, a conforming processor could replace tabs in a program with blanks while transcribing the program from a storage medium. For such a processor, programs whose representation on a storage medium contains tabs could be a conforming program. Bob Corbett
From: Richard Maine on 16 Apr 2010 22:39 <robert.corbett(a)oracle.com> wrote: > The presence of tabs in the representation of a program on > a storage medium does not preclude the program from being > standard conforming for a given implementation. True in the abstract, for the reason that you state. But the "for a given implementation" bit is central to the point. Using tabs in the source code is detrimental to portability because such a representation is not, in practice, portably interpreted among implementations. In fact, although I agree that, in the abstract, a processor could consider the tabs to be part of its "method of transcription", I'm not aware of any processors that actually claim that. There are processors that claim to support a tab source form as a language extension, but that's different from claiming that it is part of the method of transcription as referred to in that part of the standard. If they did claim such support, they would need to do some niggly bits appropriately; for example, character literals had better get it appropriately "right". I bet the OP's processor doesn't do that. In more specific support of my claim that such a transcription method is detrimental to portability, when I tried to copy the source code in question from the posting here, it failed to copy in such a way as to correctly interpfret any such transcription method that might theoretically have been intended. Instead, the compiler that I tried reported it as being a nonstandard tab format. Therefore, if this code was standard conforming for some particular implementation (which I doubt), then it did not manage to copy appropriately for the implementations that I have. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: glen herrmannsfeldt on 16 Apr 2010 23:36 robert.corbett(a)oracle.com wrote: (snip) > The presence of tabs in the representation of a program on > a storage medium does not preclude the program from being > standard conforming for a given implementation. Section 1.4 > of the Fortran 2003 standard states > This standard does not specify > . . . > (3) The method of transcription of programs or > their input or output data to or from a > storage medium, > For example, a conforming processor could replace tabs in a > program with blanks while transcribing the program from a > storage medium. For such a processor, programs whose > representation on a storage medium contains tabs could be > a conforming program. At least back to Fortran-10 on the PDP-10/TOPS-10 systems. The thing that I didn't like about that was that tabs were, by system definition, every eight columns. A tab at the beginning of a line went to column 8, but the compiler counted it as column 7. It would print out in listings at column 8. Well, the other way to look at it is that lines go until column 73 if they start with a tab. That part I didn't like. I didn't use tabs in my Fortran programs. If instead it counted as column 8 (so one fewer available for the Fortran statement) then listings would be consistent, and programs that convert to/from tabs would result in compilable results either way. -- glen
From: J. Clarke on 17 Apr 2010 01:07 On 4/16/2010 1:48 PM, steve wrote: > On Apr 16, 10:06 am, "J. Clarke"<jclarke.use...(a)cox.net> wrote: >> On 4/16/2010 11:41 AM, Richard Maine wrote: >> >> >> >>> J. Clarke<jclarke.use...(a)cox.net> wrote: >> >>>> But code with comments containing in the first column _is_ perfectly >>>> valid Fortran code. >> >>> No, it is not. Not in free source form, which is what you were talking >>> about. That is only valid in fixed source form. See he standard. It >>> isn't worth me dragging out the standard to cite the exact words, as it >>> is too trivial. Commentary conventions are part of source form. >> >>> There are no special columns in free source form; that's most of the >>> whole point. Specifically, column 1 is not special. The closest thing to >>> a column number dependence in free source form is that there is a limit >>> of 132 default characters of a free source form line. >> >>> If you have managed to find *ANY* compiler that gets this wrong, I would >>> be very intrigued. That ought to be a bit of a hint itself, although not >>> technically definitive. If one, or maybe a few, compilers refuse to >>> compile something, then a compiler bug is at least a possibility. Most >>> often it is an error in the code - often enough that it should be the >>> first assumption. But if every single compiler refuses to compile >>> something, that should be a pretty strong hint that maybe the code isn't >>> valid. >> >>> Note that the means of specifying whether code is free source form or >>> fixed source form is a separate matter. That part is not specified in >>> the standard. In particular, you might find a compiler that will accept >>> a file with a name ending in .f90 as fixed source form (I'm pretty sure >>> that gfortran will do so if you use an appropriate switch), but that's >>> not the matter at hand. I mention it only in case you might incorrectly >>> think you had found a counterexample just because you found a compiler >>> that would compile the code with a .f90 extension. >> >> I stand corrected, and that then points to another bug in the sample >> given. It uses "c" in the first line for comments but several lines >> start in the first six columns, so it adheres neither convention. > > Please read the Fortran Standard. And what do you believe it will tell me? > The code is fixed-form source > code. So it's OK for fixed-form source code to have the word "end" starting in column 5? > The only non-standard item I see on a quick glance is the > use of 'real*8' instead of 'double precision'. Compile it and get back to us. I didn't take a quick glance, I compiled and ran it. > Indeed, ftnchek > shows that the code conforms to the Fortran 77 standard with > the exception of 'real*8', one variable name longer than 6 characters, > and two variables with an underscore in the name. So it _is_ OK for the word "end" to appear in Column 5? > > -- > steve
From: robert.corbett on 17 Apr 2010 01:47
On Apr 16, 7:39 pm, nos...(a)see.signature (Richard Maine) wrote: > <robert.corb...(a)oracle.com> wrote: > > The presence of tabs in the representation of a program on > > a storage medium does not preclude the program from being > > standard conforming for a given implementation. > > True in the abstract, for the reason that you state. > > But the "for a given implementation" bit is central to the point. Using > tabs in the source code is detrimental to portability because such a > representation is not, in practice, portably interpreted among > implementations. In fact, although I agree that, in the abstract, a > processor could consider the tabs to be part of its "method of > transcription", I'm not aware of any processors that actually claim > that. There are processors that claim to support a tab source form as a > language extension, but that's different from claiming that it is part > of the method of transcription as referred to in that part of the > standard. If they did claim such support, they would need to do some > niggly bits appropriately; for example, character literals had better > get it appropriately "right". I bet the OP's processor doesn't do that. > > In more specific support of my claim that such a transcription method is > detrimental to portability, when I tried to copy the source code in > question from the posting here, it failed to copy in such a way as to > correctly interpfret any such transcription method that might > theoretically have been intended. Instead, the compiler that I tried > reported it as being a nonstandard tab format. Therefore, if this code > was standard conforming for some particular implementation (which I > doubt), then it did not manage to copy appropriately for the > implementations that I have. Transferring files between file systems that use incompatible file formats is always going to be an issue. I have used FORTRAN compilers where every line of a source program had to be the same length because the file system stored text as fixed-length records. Some people now think that transferring source files between Windows, Macs, UNIX, and UNIX-like operating systems is a bother because of the different line terminators. They have no idea how much trouble transferring source files used to be. Of course, the fact that each machine had its own character set(s) made such transfers all the more interesting. One advantage of using fixed-length records was that it was possible to consider any character that was representable on the machine as a member of the FORTRAN processor's processor character set. That was not possible for systems that used control characters to designate the end of a line. The FORTRAN 77 standard required a FORTRAN processor to allow any character in the processor's processor character set to appear in a character context. Whatever characters were used as line terminators were excluded from the processor character set. Typically, a few other characters were also excluded from the processor character set, tabs and form feeds frequently among them. Bob Corbett |