Re: Converting fixed-to-free format
- From: "robin" <robin_v@xxxxxxxxxxx>
- Date: Tue, 04 Apr 2006 11:04:28 GMT
James Giles wrote in message <5cEWf.649896$qk4.437327@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>...
robin wrote:
James Giles wrote in message ......
The program
would continue to work exactly as before in spite of the *crap*
past column 72. You would just be getting *ONE* summary
warning message telling you what a fool you
You conveniently forget that a few posts ago, I twice pointed out
that that doesn't happen.
The compiler I mentioned writes out 3 lines of message for
each and every such long line.
In a 10,000 line program you could get 30,000 lines of error
messages. That's real smart for you to keep suggesting that your
proposal
is only going to give you one message.
A bad implementation is no reason not to require useful
functionality. You are on record as using this bad implementation
as an excuse to do harm by denying people a useful diagnosic.
You are LIAR. You know I never said that. You made it up.
I never said that.
On the other hand, you are on record as promoting a scheme that
is not beneficial to users of fixed form source.
Indeed, by your promoting this, you are suggesting to users that
it's OK to use fixed source form, when it isn't. It's error-prone.
are for still
using such an obsolete mechanism in your code. (Most of the
rest of us have no code left at all with such *crap* in it.)
Has it occurred that there are billions of old codes out there?
Old code is *CRAP* by definition until it has been thoroughly
vetted. Part of that process is verifying that it contains no
errors due to inadvertant long code lines. Part of doing that
is to remove all the other *CRAP* past column 72. There's
no substite: you're going to have to read every line of code
that has stuff past column 72. For *most* fixed-form code
(most *doesn't* have sequence numbers, undelimited comments,
or anything else *deliberately* out there),
It doesn't? Comments regularly drift off up to column 80,
which is the typical width of a screen. There no great compulsion
to stop on or before column 72, as it's only a comment.
a warning that leads
the reader to the specific line would be very useful.
Your suggestion doesn't lead anyone to a specific line.
I have *always* stated that the proper implementation is
to write *ONE*
But you are in fairyland, because compilers don't do that.
You're the one in fairlyland by supposing *ONE* bad
implementation of the feature is the *required* behavior
of all future implementartions.
You will find that other compilers also what I reported.
Eventually fixed source form will become obsolete,
as it's an error-prone form.
By default you would get *ONE* summary message at the end
of the processing of each program unit in that case (as stated
many times before, and repeated in this paragraph *twice*
now).
So, in a large program with, say, 1000 subroutines,
could we expect to see 2000-3000 lines of error messages?
Yes. When processing a code that long that's not been
modernized, you should expect *lots* of messages.
Yes, you would get 2000-3000 lines of error messages
from your suggestion.
On top of that there will be real error messages about
other errors that have been detected.
Will you be able to find them among the 2000-3,000+ error messages
about legitimate lines?
These
will be the tip of the iceburg. You'll have hollerith literals
to deal with (probably ones that assume some other code
than ASCII and some exotic number of characters per word).
With code that old, you'll have SENSE SWITCH statements.
I doubt it. Code could be as late as 1990 and probably later.
By this time sense switches had long gone.
You'll have unusual hardware and compiler dependent extentions
that *NO* modern compiler supports. You'll have to fix all of those.
Cleaning up lines longer than 72 characters will be a first step -
making the code easier to read by deleting all the *CRAP* past
column 72.
What you call "CRAP" includes comment documentation.
And, a code that old with that many lines is *not* a typical situation.
It's more rare than hen's teeth.
You will find them out there.
Typical codes of *today* dealing
with fixed-form source don't have those problems, have been
written more recently than the dark ages (or have been modernized
since then), and don't (deliberately) have *crap* past column 72 at
all.
Don't talk rot. Codes do.
A warning when they've inadvertently gone past column 72
would be very useful to a *vast* majority of fixed-form Fortran
users.
A warning that they should be using free source form
would be far more useful.
You're promoting an archaic error-prone form that
will always be error prone no matter what.
You pontificate about "doing no harm", but you are positively
promoting an obsolete error-prone form.
(Similarly, exactly such a warning, with respect to column
132, would be useful to free-form Fortran users. The same issue exists
there.) The purpose of the standard should be to support the majority,
not the poor rarity with uncorrected code from predeluvian times
still on his hands. Such a person has problems with or without
the warning messages discussed here. And, long lines are usually
the least of his problems: addressed by simply stripping them off
(while reading through the source to make sure none of it supposed
to be code).
At *NO* time have I ever recommended thousands of
diagnostic messages be produced. That's in your fevered
imagination.
I'm just pointing out that compilers don't do that.
If they check at all, they produce one message for each
violation.
You have referenced *ONE* compiler (that I don't have
an increasingly disbelieve your characterization of) that
does so. That's not evidence that *all* compilers in the
future will do so. Nor is it a reason not to require that
compilers of the future should warn.
You still haven't listened.
Getting thousands of lines of messages in a long program
is not helpful.
Only if no one has removed the obsolete *crap* as should
be done as an inherent part of verifying the code is suitable
for modern use.
And if the "obsolete *crap*" is comments?
Marvellous.
A comment is something preceeded by a comment marker.
That is, either column one contains an asterisk (*) or the
letter C, or some subsequent character outside (of character
context) is an exclamation point(!). Anything beyond column
72 without being part of a comment (as defined in this paragraph)
is *CRAP*. You can make it acceptable by preceeding it with
an exclamation point. No warnings will then ensue. Of course,
most such *crap* probably really is *crap* and should be deleted
anyway (sequence numbers, etc). If it's really commentary, it's of
no use in that role unless you read it. You can't have it both ways,
either it's worth reading (and you can put an exclamation point in
as you do so), or you might as well throw it away.
You are still promoting that progrrammers dispense with comment
documentation.
This is important in any program, but probably especially
important in an old program, and important in a long program.
Do no harm. Practice what you preach.
You, on the other hand, are clearly on record as opposing
any mechanism that will help people with *modern* code
avoid a common pitfall.
You talk rot. You made that up.
I'm on record as helping users to avoid errors including the one
you are on about.
The only statements you've made on the subject have been to
insist that the compiler should not warn. I predict you won't:
but please post the Google archive URL of any article in
which you've made any productive attempt to help people on
this issue. You haven't. You are lying.
No; I did not lie. IT IS YOU WHO IS THE LIAR,
because I never said that. You made it up (again),
and you KNOW it.
If you /were/ /actually/ interested in helping people find
errors in their old programs, you would be promoting that they convert
those old codes to free source form.
That's right, and I *have*. First step: remove all *crap* from
past column 72.
Again, you do harm. You want programmers to remove comments
that extend beyond column 72.
In any case, you have not said anything along
these lines until *now*
You are LYING. Whenever this issue has come up in this forum,
I have recommended that the OP use free source form.
I have itemised the benefits IN POINT FORM when I have done so.
I do not recall your ever having done likewise, but you might have.
What I do know is that in this thread you have repeatedly promoted
the perpetuation of fixed source form.
and you still haven't promoted any
useful mechanism to help in the process.
Yes I have. I have recommended the use of FREE SOURCE FORM.
A warning about
unintentional long lines is exactly such a mechanism since
otherwise the temptation would be to use a conversion tool
that silently ignores everything past column 72. That would not
necessarily meet the user's needs if what he wanted was a
*correct* conversion of the code. There are billions of lines
of broken code in the world. Probably quite a lot of which
suffer from this very problem.
And you're still ignoring that fact that free-form suffers the same
problem: the standard does not define what to do with lines longer
than a fixed limit (132 in this case). There should be a warning
there. You've opposed it.
No I haven't. You are a LIAR. Find where I have said that
long lines in free source form should not elicit a warning.
You can't, because I never said that. You are a LIAR.
In case you didn't know, compilers of free source form
do output messages for long lines. As they should.
But that is a completely different kettle of fish.
Columns beyond 132 have not systematically been used
for sequencing. And in any case, users could place sequence
information anywhere, with an exclamation point
before them, making them comments.
It is far less likely that 132 columns will be exceeded than 72 columns
(well, actually, 66 columns, which is quite a short area for the body
of a statement, which is another reason that it is so easy to
venture past column 72 with the body of a statement.
Anyone who wants to take the advantages of free source form
can do so with a program they can easily write themselves to convert
fixed source form to free source form. Or use one of the conversion aids.
.
- Follow-Ups:
- Re: Converting fixed-to-free format
- From: jamesgiles@xxxxxxx
- Re: Converting fixed-to-free format
- Prev by Date: Re: fortran code for 'cp' / subroutine file_copy
- Next by Date: Re: gcc 4.0 fortran frontend
- Previous by thread: Explicit and implicit interfaces
- Next by thread: Re: Converting fixed-to-free format
- Index(es):
Relevant Pages
|
|
