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 

No_Truncate

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



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

PostPosted: Mon Jun 10, 2019 7:44 pm    Post subject: No_Truncate Reply with quote

Why compiler with /no_truncate gives only the warning and not an error? What the sense in this case is for this key ?

WARNING - Line has been truncated (line is longer than 132 characters)

Warning like that compiler has to provide in any case with or without /no_truncate

When there is no "implicit none", your code is large, and compiler always warns you about numerous things, you will never notice any new warnings to your 100000 old ones Smile

a1234567890=1
b1234567890=2
c1234567890=3
d1234567890=4
Write(*,*)'1234567890123456789012345678901234567890123456789012345678901234567890', a1234567890, b1234567890, c1234567890, d1234567890
end


Compilation
C:>FTN95 zzz.f95 /link /no_truncate
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Tue Jun 11, 2019 8:01 am    Post subject: Reply with quote

/NO_TRUNCATE is for fixed format files. There was no thought that it would be useful for free format files.
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1203
Location: Aerospace Valley

PostPosted: Tue Jun 11, 2019 12:12 pm    Post subject: Reply with quote

where's the documentation for /NO_TRUNCATE
can't find it anywhere, neither in the on-line nor .chm help 'Compiler Options'

*Update*
it is in the command line ftn95 /? where it says:
Quote:
/NO_TRUNCATE Truncated lines are not permitted.


Thus I'd expect that (for Fixed Format code) there would be a FATAL Error message and not just a Warning, toing error messages due to truncation. avoid all those result

For Free Format it would be more appropriate to have just the Warning Message since it is indicative and wouldn't result in consequential errors.

132 was mentioned above but is that the actual limit for 'Free Format' or is it higher (or unlimited even ?)
_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... Smile "
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Tue Jun 11, 2019 1:45 pm    Post subject: Reply with quote

John-Silver

Thank you for the feedback.

/NO_TRUNCATE provides an error report and not a warning but only for fixed format files. I will add /NO_TRUNCATE to the help documentation and update the FTN95 /? response.

The default for free format files is 132 characters and this can be extended by using /WIDE_SOURCE.
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Tue Jun 11, 2019 7:35 pm    Post subject: Reply with quote

Paul, do you see any problems extending it to 132 ?
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Tue Jun 11, 2019 9:24 pm    Post subject: Reply with quote

I don't know but I can take a look.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Wed Jun 12, 2019 9:41 am    Post subject: Reply with quote

It would require a non-trivial change and I am not sure that it is worth it. The simple fix does not work when the truncated part is a comment.

An alternative is to upgrade warning number 684 to an error via the command line option....

/message_set_to_error 684

This results in...

error 684 - There are (at least) 1 truncated line(s) in this file

but this could still be a false report when the truncated part is a comment.
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1203
Location: Aerospace Valley

PostPosted: Thu Jun 13, 2019 7:38 am    Post subject: Reply with quote

Paul,
it would need only that each error is highlighted seperately, wth it's line number where it occurs, for that method to become useful.
_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... Smile "
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Thu Jun 13, 2019 8:33 pm    Post subject: Reply with quote

Paul,
Trusting compiler more than myself after truncation warning was set to error and then /no_truncate was introduced i just discovered deadly bug which was for 2 years when the limit which was hit was for 132 characters. Finding bugs becomes damn hard task when code is large, amount of possible reason for the bug growing so much that you feel totally lost. Now my first reaction on ANY problem with my codes is "Oh no...".

The truncation errors are the most hidden and will occur more and more often. This is because monitors become wider and wider and other languages (like HTML) show dumb examples of no limit lines (where i have seen >1000 character wide lines). So breaking the 132 character line limit in Fortran soon will be a common problem.

Since integer and real math is so different i do not find it wise to move to "implicit none" generally just to avoid truncation and initialization errors because we will introduce even more hidden errors by mixing up integer variables starting with ijklmn thinking they are of type of integer but they are real or vise versa. You will be lazy to go 100000 lines up to check their definitions in the header which is as long as the phone book of decent size city. And with FTN95 programmer does not worry about forgetting initializations since FTN95 fights initialization errors with /undef or /checkmate and meantime these switches also check much more hidden code flow errors than initializations. It is much better to restrict yourself and know for sure immediately that variable starting with ijklmn is integer type, otherwise the code becomes barely manageable.

So, in my opinion, for the time being until all the limits like 72 and 132 will be in the past (for the net 20 years i think) the full fledged /no_truncate has to be implemented and even more - it has to be a default when you chose /full_debug
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2135
Location: Sydney

PostPosted: Fri Jun 14, 2019 2:39 am    Post subject: Reply with quote

Dan,

Why don't you write a program that scans for lines longer than 132 characters and also for <HT> characters.
You could either open the file using transparent:
Code:
      open (unit   = 11,               &
            file   = file_name,        &
            status = 'OLD',            &
            form   = 'UNFORMATTED',    &
            access = 'TRANSPARENT',    &
            iostat = iostat)
      write (*,2000) 'Opening file ',trim(file_name),' iostat = ',iostat
2000  format (a,a,a,i0)

or use normal reads and
Code:
         OPEN (LIN, FILE=NAME, STATUS='OLD', ACTION='READ', IOSTAT=IOSTAT)
         call READ_TABS@(LIN)

I have found scanning code for tab characters is useful, especially when reviewing code downloaded from forums.
The old fixed format 7:72 limits are a bit more work, as I still have some old code with line numbers and edit notes in columns 73:. Makes for interesting bugs when you change the file name from .for to .f90 or .f95 !

John
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Fri Jun 14, 2019 11:48 am    Post subject: Reply with quote

/NO_TRUNCATE has now been extended so that it also works for free format files. The new feature will be in the next release of FTN95.
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Fri Jun 14, 2019 11:20 pm    Post subject: Reply with quote

Thanks Paul for good news.

John, I have written such program for 72 characters 20 years ago and the conclusion is - i used it few times per year when some tough error had no explanation and this was useful. But using it every time was inconvenient. Still over long period of time like a year there was usually one case of such error. That means that the code was actually a lot of time - months - in buggy state. This is why /no_truncate could be very useful.

I started writing exclusively 132 wide sources only few years ago and thought that the problem with truncation for both 72 and 132 wide sources have been solved with introducing initially workaround by pushing truncation warning to be an error and then with /no_truncate compilation switch. Unfortunately both of them were working only for 72 character sources and as a result i thought for 2 years that opacity effects do not play any role in some our cases (and even rationalized some dumb explanation for that which was barely believable even to myself) but this was just plain truncation bug with source hitting 132 limit. This potentially (need to revisit this carefully) caused tremendous delay with one paper we were working for few years and still did not finish it
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1203
Location: Aerospace Valley

PostPosted: Thu Jun 20, 2019 12:52 am    Post subject: Reply with quote

Dan, your:
Quote:
and even rationalized some dumb explanation for that which was barely believable even to myself

brought back memories and made me smile.
About 20 years ago myself and a friend of mine worked here in Toulouse in an office full of french engineers.

As well as asking our advice on technical matters they also used to ask advice about english grammar.

Whatever the source of a question on either subject, especially on english questions,we'd quite often be on dodgy ground with our explanation, one of us would start to reply and then after about 3 minutes, when we were on the point of almost convincing ourselves that what we were saying was true, doubt would creep in, we'd look at each other other and we'd both finish with ....
'Plausible but abolute f-ing nonsense !' LOL
_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... Smile "
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 -> General 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