From: J. Clarke on
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
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
> there is a limit of 132 default characters of a free source form line.

And boy, does that suck.

--
FX
From: Richard Maine on
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
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.


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