forums.silverfrost.com

[jcherw]

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

[PaulLaidler]

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.

[PaulLaidler]

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.

[PaulLaidler]

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.

[PaulLaidler]

You can only test conclusively for undefined values at runtime.
The compiler can and does provide a compile time warning in some contexts.