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:

	aaaaaaaaaaaaaaaaaaaaaaaaaaaaa     = 1
	bbbbbbbbbbbbbbbbbbbbbbbbbbbbb     = 1 - aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
       	print*, bbbbbbbbbbbbbbbbbbbbbbbbbbbbb 
        end

1.     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.

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.

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

OK I will add the option. Do you want to suggest a name? /no_line_truncation?

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.

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?

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?

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

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.

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

	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...

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.

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).

!       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

!       example
        parameter (modeErr=0,ModeAbcdefg=3,ModeCredar=4,Modetrim=5)	! Tab before excl.m.
        print*,   modeErr
        end

Diagnostics for both snippets is:

2.     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.

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?

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 😄

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