Prev: GCC/gfortran 4.5.0 release
Next: linking not done
From: steve on 16 Apr 2010 13:48
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. The code is fixed-form source
code. The only non-standard item I see on a quick glance is the
use of 'real*8' instead of 'double precision'. 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.

--
steve
From: Richard Maine on 16 Apr 2010 14:02
J. Clarke <jclarke.usenet(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. Now that I
think on it, I think someone mentioned that earlier as an aside

--
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 14:24
Richard Maine <nospam(a)see.signature> wrote:
(snip)

> 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. Now that I
> think on it, I think someone mentioned that earlier as an aside

I mentioned tabs in the discussion on conversion error. I didn't count
the columns, but didn't see any non-numeric characters in the data.
I thought that the line breaks in the middle of numeric values were
part of the post process, and not part of the data. I then considered
that tabs in input data could be considered conversion errors.

-- glen

From: FX on 16 Apr 2010 16:26
> 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.

It would be much more useful if the standard required the compiler to
accept lines of any length. After all, the standard places no restriction
on the number of lines in the program, why should it have a restriction
for columns (other than historical reasons)?

I don't argue for removing the limit, I argue for replacing the limit
with infinity.

--
FX

From: glen herrmannsfeldt on 16 Apr 2010 16:35
FX <coudert(a)alussinan.org> wrote:
>> 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.

> It would be much more useful if the standard required the compiler to
> accept lines of any length. After all, the standard places no restriction
> on the number of lines in the program, why should it have a restriction
> for columns (other than historical reasons)?

> I don't argue for removing the limit, I argue for replacing the limit
> with infinity.

When they start making computers with an infinite amount of
memory, then they might do that.

Note, for example, that some systems store records (lines) with
a length field in a finite number of bits.

The standard used to have a limit on the number of continuation
lines, which allows one to size a buffer big enough to hold all
the lines of one statement.

As Richard said, the limit is the minimum required. An implementation
might allow for infinity, but it isn't likely the standard will
be change to require that, as not all systems can support it.
(Actually, none can...)

-- glen
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7
Prev: GCC/gfortran 4.5.0 release
Next: linking not done