forums.silverfrost.com

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

John,

What are the code security reasons that may impact on my programs ?

When a program crashes, for unknown reasons, it is much better to get a traceback with useful information, than the alternative of a traceback full of ######.

I think it is unlikely that someone would hack into my program and modify some routine link to another .dll. More likely, they would hack into a system .dll, if such a thing is a possibility.

Where is this security risk ?

LitusSaxonicum · Posted: Sat Apr 25, 2020 1:30 pm Post subject:

Does it make the program run faster as well?

E

Robert · Joined: 29 Nov 2006 Posts: 457 Location: Manchester

It may make the program load a little quicker. The documentation would have been written twenty years ago when a bit of extra size of your executables may have mattered more.

LitusSaxonicum · Posted: Mon Apr 27, 2020 7:47 am Post subject:

Loading times are one of the two factors that give a user a subjective assessment of the speed of a program - obviously one can measure these times, but many users will not. If the run time is long, then the load time pales into insignificance, and vice versa.

I suppose that I am fortunate in that with the computers at my disposal, the algorithms that I use and FTN95 neither is of much concern to me personally, but they may be to others, and I can't imagine any argument if favour of making either load or run times longer except 'the results flashed by so fast I couldn't read them'.

A benefit of an SSD in comparison to a mechanical hard drive is in decreasing the load time, as - especially with a Windows interface and expected user interaction - the human response is the limiting factor. The reduction in load time must therefore be a valuable by product of the removal of runtime tracebacks.

Incidentally, one hopes that crashes in production software are infrequent events, and frankly, the traceback information may as well be written in Sanskrit for all the good it does for the average user if they are not the original programmer, and even if they are, there's a good chance that it will not mean much!

LitusSaxonicum · Posted: Mon Apr 27, 2020 1:24 pm Post subject:

John,

Remember that to the compiler writer, catching a programmer error and exiting with an error message (however cryptic) is not a crash - it's a graceful exit and the traceback is part of that 'grace'. Not to have a traceback is a programmer choice, and it is one, I suggest, that the programmer takes when he/she/it/Xe is confident there will be no programmer errors.

FTN95 and Windows bugs normally don't come with any notification at all - except Mecej4 for the former and the BSOD for the latter!

Eddie

mecej4 · Joined: 31 Oct 2006 Posts: 1899

No extended debate is needed regarding the availability of a traceback as a default or only when requested.

If you want a traceback most of the time, you can add /debug to your FTN95.CFG file. Since FTN95 does not attempt more than modest optimisations, the runtime speed penalty for using /debug as a default option is quite modest. If, on the other hand, you do not want your customers to know even the names of the subroutines, you may consider not allowing traceback information to be ever seen by end users. Similarly, if you have some users who will experience angst upon seeing a traceback, ...

In the course of program development, tracebacks are quite useful, but are by no means sufficient. A program termination with traceback does not tell the programmer whether the problem occurred during the first run through the chain of subroutines it displays, or the umpteenth time. In such cases, additional instrumentation of the program may be needed to find and fix bugs.

If your software uses routines from subroutine libraries such as NAG or IMSL, the traceback information will be incomplete unless the library also includes traceback information for the routines that it exposes.