forums.silverfrost.com

[louis]

Dear support

I have noticed that in many instances, run time errors due to (for instance) unassigned variables no longer raise a message box. This is shown even by the following trivial program

program main
real :: a,b

b = sqrt(a)
write(*,*) b
end

When just compiled with /link/debug it returns 0.0, so obviously the unassigned variable a has been initialised. But with /link/full_undef/debug
it just stops (with a warning noise from Windows).
Is there a flag to get back to the old behaviour, which makes it so much easier to debug code ?

I am using version 5.10 at the moment because of problems with 5.20 but I can't recall reading that anything to do with this has been changed.

Regards
Louis Farrugia

[PaulLaidler]

Louis

It will take a little while to check out all of the details but here are my initial thoughts.

You need /undef or its equivalent to get a runtime message that "a" has not been assigned. I get the message when using /lgo and when using /link and then running via SDBG. This particular program also generates a compile time warning when compiling with FTN95.

I also get a beep and termination when I just run the program but at the moment I do not know if this marks a regression or a bug in salflibc.dll (also I am not using the current release of this DLL). I will look into this as soon as I can.

There is a patch for FTN95 (version 5.20.1) available and a new release will be out very soon. But the questions raised here relate more to salflibc.dll since this gives you the runtime response for undef etc.

Paul

[PaulLaidler]

This bug has now been fixed.