View previous topic :: View next topic |
Author |
Message |
DanRRight
Joined: 10 Mar 2008 Posts: 2834 Location: South Pole, Antarctica
|
Posted: Sun Sep 05, 2010 6:32 am Post subject: Over 72 and 132 column |
|
|
Please add compiler option to make it an error if the source goes beyond the line limits. Now compiler makes only vague warning at the end of the compilation (telling how many lines are truncated) which we often miss. The problem when you hit the line limit is diagnosed incorrectly. Here is 72 column example:
Code: | aaaaaaaaaaaaaaaaaaaaaaaaaaaaa = 1
bbbbbbbbbbbbbbbbbbbbbbbbbbbbb = 1 - aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
print*, bbbbbbbbbbbbbbbbbbbbbbbbbbbbb
end |
0001) aaaaaaaaaaaaaaaaaaaaaaaaaaaaa = 1
WARNING - Variable AAAAAAAAAAAAAAAAAAAAAAAAAAAAA has been given a value but
never used
0002) bbbbbbbbbbbbbbbbbbbbbbbbbbbbb = 1 - aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
WARNING - Variable AAAAAAAAAAAAAAAAAAAAAAAA has been used without being given
an initial value
NO ERRORS, 2 WARNINGS [<main program> FTN95/Win32 v5.50.0]
I've made pure 100% error but compiler gives only a warning.
Why by the way compiler finds TWO truncated lines ? And why breaking 72/132 is not a strict full fledged fat bad a$$ error? That's typical and dangerous bug, easily capable to evaporate your day.
Last edited by DanRRight on Mon Sep 06, 2010 7:54 am; edited 1 time in total |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7938 Location: Salford, UK
|
Posted: Sun Sep 05, 2010 8:44 am Post subject: |
|
|
I will think about this but in the mean time your problem might be solved by upgrading the warnings to errors. I will have to look up the details but as I recall you can do this by configuring FTN95 (/config on the command line) or directly for each compilation. |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2391 Location: Yateley, Hants, UK
|
Posted: Sun Sep 05, 2010 6:30 pm Post subject: |
|
|
Dan,
What you did is a human error. The code - with truncation OR without - is valid Fortran. FTN95 gives a warning when some compilers give nothing.
Not getting a listing on a line printer like we used to has permitted this sort of problem to arise. Your suggestion is a valuable one.
Will compilers ever be smart enough to tell us that what we wrote isn't what we meant? It would be useful, wouldn't it?
Eddie |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7938 Location: Salford, UK
|
Posted: Mon Sep 06, 2010 7:32 am Post subject: |
|
|
OK I will add the option. Do you want to suggest a name?
/no_line_truncation? |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2834 Location: South Pole, Antarctica
|
Posted: Mon Sep 06, 2010 7:52 am Post subject: |
|
|
or just /no_truncation or /NOTRUNC to keep the style of 50th . Also
/report_truncation or
/enforce_truncation
Thanks, that kind of feedback and help is awesome.
Yes, formally, this is valid Fortran. But even compiler itself does not believe that this is what i've meant LOL. Look at its diagnostics at line 0002, it shows correct expression! Then it still takes formal route and issues me a WARNING on the next line which is formally right but by sense is wrong LOL
Things are that we more and more are using free style of latest Fortran with its longer lines. And at the same time we re-use our older Fortran-77 subprograms as is, without turning them into free-style long line sources.
The result of this is permanent brake through the boundaries and exponentially increasing difficulties to find the bugs with the code grow.
So we have to decide what's to sacrifice. I'd accept restriction that if i strictly did not tell the compiler that this is the end of line means that this is an error. Or i will not find some my errors till the end of the world. |
|
Back to top |
|
|
sparge
Joined: 11 Apr 2005 Posts: 371
|
Posted: Mon Sep 06, 2010 10:46 am Post subject: |
|
|
I'm a bit baffled at the suggestion that this is a human error and not a bug in code. I'm 100% with Dan on this. Never having really thought about it before, I'm also surprised that compilers in general are not more hard-line about it. Surely a character count per line is a very easy preliminary sense-check? |
|
Back to top |
|
|
sparge
Joined: 11 Apr 2005 Posts: 371
|
Posted: Mon Sep 06, 2010 10:47 am Post subject: |
|
|
I'm a bit baffled at the suggestion that this is a human error and not a bug in code. I'm 100% with Dan on this. Never having really thought about it before, I'm also surprised that compilers in general are not more hard-line about it. Surely a character count per line is a very easy preliminary sense-check? |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2560 Location: Sydney
|
Posted: Tue Sep 07, 2010 4:26 am Post subject: |
|
|
Old fixed format 72/80 card format allowed comments in columns 73-80. (was there continuation column 73 or is that fixed-free format compatibility ?)
Some old codes used this for the card number, in case you dropped the box !
Now, it would be a simple change to place an ! before these comments.
It may be an option to place a warning on each line that is truncated ? rather than the count of truncated lines, especially if using free format (132 character)
The option of extending free format beyond 132 would be a good non-standard extension, although if I had a warning on the line, I'd fix it.
My IDE changes the text colour beyond the limit.
John |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7938 Location: Salford, UK
|
Posted: Tue Sep 07, 2010 7:16 am Post subject: |
|
|
John
There is already an option /WIDE_SOURCE that removes the 72 and 132 limits.
If your IDE is not Plato then users will find that Plato (and the FTN95 plug-in for VS, at least for fixed format) also provides syntax colouring for comments. |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2834 Location: South Pole, Antarctica
|
Posted: Tue Sep 07, 2010 8:59 am Post subject: |
|
|
I am compiling and debugging now someones 3MB Fortran source code which gives me 280KB file of Warnings. Add to this also a hundred of reported truncated lines which i need to find myself. Another source of 7MB of Fortran text generates 380KB of warnings in 8 seconds of its compilation LOL
That means that it is practically impossible to find your own bug if you will brake the 72/132 limit. You never look at this massive unload of warnings about not used labels or variables...
It is unrealistically also to fix all these warnings since these labels or variables were used and are left possibly because are intended to be used in the future. Forcing compiler to consider warnings as errors is often almost impossible or inconvenient.
Paul, i've also noticed the following ambiguity/bug in diagnostics which could have negative consequences with this new option. The following line
Code: | parameter (modeErr=0,ModeAbcdefg=3,ModeCredar=5,Modetrim=6) ! 20100906 note the Tab is used before exclam. mark |
is explicitly reporting different kind of truncation warnings:
WARNING - Line has been truncated (line is longer than 72 characters) (In include file Z:\DEBUG\12034565\MNB4433\rrr.tree.f)
In this code's line the tab is used before the "!" sign (which in turn is on 73 position). This line in the code works fine of course. And this is how we usually make own comments in the source as John also mentioned. By sense we do not have to receive any warnings about truncation in this case. Will we get error here with this new /no_line_truncation option ? That would kill this new option...
Last edited by DanRRight on Tue Sep 07, 2010 11:39 am; edited 1 time in total |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7938 Location: Salford, UK
|
Posted: Tue Sep 07, 2010 10:57 am Post subject: |
|
|
I am not sure what is happening here but the exclamation mark would need to be in column 72 if the comment does not go beyond the 80 card width.
Any tabs would be translated by the compiler as 8 spaces and would also take the width beyond 80.
I can probably arrange for the new option to have no effect for included files.
When I look into it I will keep this particular case in mind. |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2834 Location: South Pole, Antarctica
|
Posted: Tue Sep 07, 2010 11:28 am Post subject: |
|
|
May be something is lost in my example. By some reason the tab before the "parameter" is keeping to be lost in the post. Add this tab if this example will lose it. This is completely working code that reproduces this feature. The line does not have to be in include file, just use another Tab after the text ....Modetrim=5) and the exclamation mark has to be in 73th position (it will be there automatically).
Code: | ! example
parameter (modeErr=0,ModeAbcdefg=3,ModeCredar=4,Modetrim=5) ! Tab before excl.m.
print*, modeErr
end |
Or here is the same code where leading Tabs substituted by spaces
Code: | ! example
parameter (modeErr=0,ModeAbcdefg=3,ModeCredar=4,Modetrim=5) ! Tab before excl.m.
print*, modeErr
end |
Diagnostics for both snippets is:
0002) parameter (modeErr=0,ModeAbcdefg=3,ModeCredar=4,Modetrim=5) ! Tab before excl.m.
WARNING - Line has been truncated (line is longer than 72 characters)
NO ERRORS, 1 WARNING [<main program> FTN95/Win32 v5.50.0]
0004) end
WARNING - There are (at least) 1 truncated line(s) in this file
BTW, if i place two Tabs, or Tab+ spaces, the warning disappears. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7938 Location: Salford, UK
|
Posted: Tue Sep 07, 2010 1:20 pm Post subject: |
|
|
I have added a new compiler option /no_truncate that leads to a compilation error if characters appear after column 72 (or 132) unless a comment has already been started before this column.
"include" files are treated in the same way.
I am not sure if this will be useful. Any old fixed format code that has line numbers etc in columns 73 to 80 will fail with this option. Is this what you want? |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2834 Location: South Pole, Antarctica
|
Posted: Tue Sep 07, 2010 7:58 pm Post subject: |
|
|
Yes, this is exactly what's needed. Nothing we can do with those older codes which just place their comments starting with 73 positions without exclamation marks in previous positions. Nobody in their right mind will put their comments without exclamation mark these days with newer free style coding unless this is machine generated source code. He will eventually pay the price with hidden bugs and unexplainable behavior of the code if he'll do.
Thanks, Paul. That's very useful diagnostics. No more scary compiler messages about 43 truncated lines in a single file LOL or no error condition when unintentionally the real brake of the boundary occurs.
Any expectations when that will be ready in new release? And of course I am ready to beta test |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2834 Location: South Pole, Antarctica
|
Posted: Tue Apr 02, 2013 6:37 pm Post subject: |
|
|
Found using Search this thread where one particular useful moment is that smart compiler (very smart, almost a genius, actually. I am sure dumb gFortran will not do that even by year 2100) should distinguish warning and error due to truncation by investigating the length of truncated variable and comparing it to something already declared so that first example code in this thread must go as an error no matter if /no_truncate used or not.
I debugged the large code the owned develops in gFortran (and also uses other compilers) recently and found with FTN95 hundreds of missed by compiler truncations. The gFortran also missed on some occasion even ENDIF and still go. LOL My claim arised from the experience is that if you did not compile your large code in FTN95 (with checkmate) your code is 100% WRONG |
|
Back to top |
|
|
|