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 

/ZERO option or equivalent for ftn95 64 bit

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



Joined: 27 Sep 2018
Posts: 15
Location: Australia

PostPosted: Fri Sep 28, 2018 12:28 pm    Post subject: /ZERO option or equivalent for ftn95 64 bit Reply with quote

I am working with a large complex and somewhat dated program (developed between 1988 and 2006) moving it to 64 bits. Running checkmate x64 results in lots of stops on UNDEF variables. I started hand-coding initial values as appropriate, but that turns out to be a lot of work. I read about the /ZERO option, which however is not available for ftn95 64 bit.

Is anyone aware of a viable alternative for the /ZERO option in ftn95 64 bit? There are a lot of arrays (few 100) declared via allocate statements.

Is there a way to conduct a zeroise along with the allocate??
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Fri Sep 28, 2018 2:10 pm    Post subject: Reply with quote

Variables that have the SAVE attribute are preset to zero. You can use /SAVE on the command line to give all local variables the SAVE attribute but this could make your executable very large.

/ZEROISE (for 32 bit applications) may not do what you may think it ought. It only has effect when used with /UNDEF and then it presets variables to zero rather than an undefined state that is used at runtime to detect undefined variables.

There is no way to combine "zeroise" with ALLOCATE but you can then set all of the elements of an array ARR to zero with the statement ARR = 0.
Back to top
View user's profile Send private message
John-Silver



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

PostPosted: Fri Sep 28, 2018 3:32 pm    Post subject: Reply with quote

SUGGESTION for SF

What would be very useful in ftn95 would be, as well as flagging individual errors as they occur, to temporarily store them, and output them to an error file in groups.
In the current case that could take the form of listing all the UNDEFined variables per routine MODULE or (SUBROUTINE or FUNCTION) in alphabetical order, even setting each to zero.
That would make any case like this one much easier for the user to tackle.
The task of initialising hundreds of variables is not difficult but daunting in terms of the data to be typed !!!
_________________
''Computers are incredibly rigid. They question nothing. Especialy input data.Human beings are incredibly trusting of computers and don't check input data. Together they are capable of 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: 5496
Location: Salford, UK

PostPosted: Fri Sep 28, 2018 4:00 pm    Post subject: Reply with quote

When an undefined variable is encountered (at runtime) an exception is raised and the application terminates. So you can only get one at a time.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Fri Sep 28, 2018 6:34 pm    Post subject: Reply with quote

I will have to check the details but it appears that 64 bit ALLOCATE automatically zeros the allocated memory unless /UNDEF (or an option like /CHECKMATE that implies /UNDEF) is used in which case the memory is initialised to the undefined state. This is not documented and may change.
Back to top
View user's profile Send private message
John-Silver



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

PostPosted: Sat Sep 29, 2018 12:34 pm    Post subject: Reply with quote

Quote:
When an undefined variable is encountered (at runtime) an exception is raised and the application terminates. So you can only get one at a time.


Fair enough.

I'm surprised it's only checked at runtime.
Even more reason to do the check at compile or link time and dump the lot.
I for one wouldn't want to be in anyone's shoes running a program hundreds of times to eliminate them one at a time.

Well worth considering.
_________________
''Computers are incredibly rigid. They question nothing. Especialy input data.Human beings are incredibly trusting of computers and don't check input data. Together they are capable of 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: 5496
Location: Salford, UK

PostPosted: Sat Sep 29, 2018 1:02 pm    Post subject: Reply with quote

You can only test conclusively for undefined values at runtime.
The compiler can and does provide a compile time warning in some contexts.
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 -> Support 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