forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Over 72 and 132 column

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Suggestions
View previous topic :: View next topic  
Author Message
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Sun Sep 05, 2010 6:32 am    Post subject: Over 72 and 132 column Reply with quote

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
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7912
Location: Salford, UK

PostPosted: Sun Sep 05, 2010 8:44 am    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Sun Sep 05, 2010 6:30 pm    Post subject: Reply with quote

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
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7912
Location: Salford, UK

PostPosted: Mon Sep 06, 2010 7:32 am    Post subject: Reply with quote

OK I will add the option. Do you want to suggest a name?
/no_line_truncation?
Back to top
View user's profile Send private message AIM Address
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Mon Sep 06, 2010 7:52 am    Post subject: Reply with quote

or just /no_truncation or /NOTRUNC to keep the style of 50th Smile. 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
View user's profile Send private message
sparge



Joined: 11 Apr 2005
Posts: 371

PostPosted: Mon Sep 06, 2010 10:46 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
sparge



Joined: 11 Apr 2005
Posts: 371

PostPosted: Mon Sep 06, 2010 10:47 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
JohnCampbell



Joined: 16 Feb 2006
Posts: 2551
Location: Sydney

PostPosted: Tue Sep 07, 2010 4:26 am    Post subject: Reply with quote

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
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7912
Location: Salford, UK

PostPosted: Tue Sep 07, 2010 7:16 am    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Tue Sep 07, 2010 8:59 am    Post subject: Reply with quote

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
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7912
Location: Salford, UK

PostPosted: Tue Sep 07, 2010 10:57 am    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Tue Sep 07, 2010 11:28 am    Post subject: Reply with quote

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
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7912
Location: Salford, UK

PostPosted: Tue Sep 07, 2010 1:20 pm    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Tue Sep 07, 2010 7:58 pm    Post subject: Reply with quote

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 Very Happy
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Tue Apr 02, 2013 6:37 pm    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Suggestions All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group