trapping of run time errors

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

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

This bug has now been fixed.