Help!! end-of-file during read, unit 1...
in [Fortran]
|
Prev: GCC/gfortran 4.5.0 release
Next: linking not done
From: J. Clarke on 16 Apr 2010 07:24 On 4/16/2010 2:08 AM, Richard Maine wrote: > J. Clarke<jclarke.usenet(a)cox.net> wrote: > >> On 4/15/2010 9:23 PM, steve wrote: >>> On Apr 15, 5:43 pm, "J. Clarke"<jclarke.use...(a)cox.net> wrote: >>>> >>>> (aside from what appears to be a known bug in >>>> gfortran regarding the use of "c" in the first column to denote a >>>> comment). > >>> A known bug in gfortran with a comment line? Can you >>> explain what you mean or point me to a bugzilla report? >> >> I'm sorry, it's a "feature". C in the first column does not denote a >> comment unless you're in fixed-form mode. > > That has nothing to do with gfortran. That's part of the language spec. > If there is any compiler that doesn't act that way, that *WOULD* be a > bug in that it would fail to correctly compile perfectly valid Fortran > code - or even worse, would compile it and give incorrect results. > (Trivial to make examples of how that would happen). I doubt that any > compilers with that particular bug exist; it probably would have been > noticed and fixed long ago. But code with comments containing in the first column _is_ perfectly valid Fortran code.
From: Richard Maine on 16 Apr 2010 11:41 J. Clarke <jclarke.usenet(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. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: FX on 16 Apr 2010 11:58 > there is a limit of 132 default characters of a free source form line. And boy, does that suck. -- FX
From: Richard Maine on 16 Apr 2010 12:20 FX <coudert(a)alussinan.org> wrote: > > there is a limit of 132 default characters of a free source form line. > > And boy, does that suck. I suspect you are looking at it backwards then. That is common with limits such as this. Look at it from the perspective of guarantee or portability. What this limit means is that, as long as you keep your code to no more than 132 columns, you are guaranteed that no standard conforming compiler will reject it for source code line length. I personally think that is a nice kind of guarantee to have. If that limit were not in the standard, then it would not mean that you were guaranteed that you could use arbitrarily long source code lines. What it would mean instead would be that different compilers could choose different limits. Some compilers might well limit you to, say, 80 columns, or even the same 72 columns as fixed source form. Maybe some oddball compiler would limit you to 64. You would have no guarantee of anything. In my opinion, that would suck. As it is now, different compilers can still have different limits. But that requirement of the standard says that none of them can be less than 132 characters. There are many limits like this in the standard where it can be worthwhile to consider the perspective of portability guarantees. When you do that, something that the standard describes as a maximum allowed in a program can often be seen as a minimum that compilers are required to support. There can be, and often are, debates about exactly what those various limits should be. They have tended to grow with time, as values that once would have been prohibitively large for some systems are now safe to assume for any system. But when people advocate removing the limits entirely, I think they misunderstand what the effects of such removal would be. For example, you might find that removing the limit of rank 7 for arrays, you code with rank 4 arrays is no longer sure to be accepted on all compilers; that probably would not have been the intended effect. A standard conforming compiler is perfectly free to allow source code lines that are 4gb (or whatever) long and to support arrays with rank 42 (if you have enough memory, or maybe if enough of the dimensions have extent 1). You just can't count on code that uses lines that long or ranks that large to be portable. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: J. Clarke on 16 Apr 2010 13:06
On 4/16/2010 11:41 AM, Richard Maine wrote: > J. Clarke<jclarke.usenet(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. |