forums.silverfrost.com

mecej4 · Joined: 31 Oct 2006 Posts: 1897

Compilation without error messages simply means that no syntax errors were detected by the compiler. Semantic errors are quite a different story. Whether the code does what the programmer wants, whether the algorithm being used is mathematically correct -- these are things that the compiler, linker and debugger cannot certify or fix. They can only help with the programmer's task.

Here is a simple example. Suppose you intended to write

z = x + y

but wrote

z = x * y

in a program. You cannot expect the compiler to read your mind and tell you to replace '*' by '+'.

With most programs, an experienced programmer can expect to spend a lot more time finding and fixing run time errors, and running tests to verify that the program produces correct results, than on syntax errors.

alangr · Posted: Mon Jan 31, 2022 8:50 am Post subject:

I certainly agree with that! The thing I do not see is how to find the run time error that stopped CALLS when working on TRADE. When I created CALLS, I used SDBG to help detect run time errors. Is it not possible to get more information than the Access Violation I reported? Can SDBG not show the (FORTRAN) code for TRADE and thus allow the error to be seen?

In the meantime, I am running SDBG on TRADE and working to fix any problems found.
_________________
Alan

JohnCampbell · Joined: 16 Feb 2006 Posts: 2593 Location: Sydney

mecej4 · Joined: 31 Oct 2006 Posts: 1897

The traceback that you showed may be incomplete. The very first line should have shown the subprogram within which a runtime error occurred. The run time error report should have also told you the nature of the error (e.g., file not found, access violation, floating point overflow, end of file, etc.).

Which versions of FTN95 and SDBG are you using? I ask because the traceback report that you showed is a little bit different from what I see from the current versions. For example:

alangr · Posted: Mon Jan 31, 2022 12:58 pm Post subject:

I suspect that I am about to be seen as very silly but I will get things together and respond to you both in due course.

In the meantime, the answer to the version query will say much as I am using FTN95 version 7.00.0. I do not know how to find the version of SDBG but I have:

SDBG.EXE and SDBGDLL.DLL both dated 7/9/2013

When I retired I wanted to continue using Fortran and bought an �academic licence� I think it was called. As you can see, I have not updated since then for two reasons. The main one is that all was working OK and I could do what I wanted to do. The second was that I was not sure that I was eligible for an update and in the face of things working, I did not chase it.

It would be good to know whether I am eligible for updates as the current versions might make debugging easier!

mecej4 · Joined: 31 Oct 2006 Posts: 1897

Please review the information on the free edition ( https://silverfrost.com/32/ftn95/ftn95_personal_edition.aspx ). If you are retired and the work that you are using FTN95 for is personal rather than commercial, you may be eligible for the 8.80 personal edition. Versions 8 and up have the capability to compile 64 bit EXEs, DLLs and LIBs. The most recent compiler version is 8.83.

alangr · Posted: Mon Jan 31, 2022 3:09 pm Post subject:

I am not running with the free, evaluation edition. I paid for a use that allowed personal work with no commercial action.

I do not have the email confirmation but my contact was Carolyn Chafer.

I am responding to JC and yourself at the moment and will send this soon.
_________________
Alan

alangr · Posted: Mon Jan 31, 2022 3:43 pm Post subject:

JC

I do not understand the nomenclature confusion you refer to. TRADE.FOR is a program in a directory \TRADE together with which are a number of subroutines. CALLS.FOR is program in another directory \CALLS together with its subroutines.

From the CALLS directory, SDBG runs CALLS, the code can be seen and no errors are indicated. Yes, both CALLS and TRADE are compiled with /DEBUG and linked using (separate) link files.

With TRADE, I have used the somewhat brief report of an error in TSTC and found the execution error. Correcting this has allowed the program to run to completion.

I am not using 64-bit.

Mecej4

As you will see from above, the limited description of the error arising from using SDBG with TRADE allowed the CALLS program to execute fully. This is good news and so I can now do all that I want to do (for the moment, anyway).

From the information you sent about current versions, if I am able to upgrade I may well get better run time error reports. Also, presumably, there would be further benefits of using a 64-bit system.

I am really sorry that there has ben confusion here, due largely to my somewhat imprecise descriptions of what is happening but, yes, I did write both CALLS and TRADE programs, though the latter has nothing to do with stocks, or French, but is a nascent �Space Trader� game written for my own enjoyment.

Work or play, though, the problems are the same.

Thank you for all your help.
_________________
Alan

mecej4 · Joined: 31 Oct 2006 Posts: 1897

JC is in Australia, and it is night there now, so I'll take one part of your description: "I do not understand the nomenclature confusion you refer to."

You have:

1. A directory called CALLS,
2. A program called CALLS,
3. A Fortran file called CALLS.FOR,
4. An EXE called CALLS.EXE,
5. CALL is a Fortran keyword, and you probably have several CALL statements in the source files, and CALL is a common verb,
6. Windows batch files may contain the CALL command.

Because of these multiple uses, it is quite easy to cause confusion when describing a program error that may involve many of these meanings of CALL.