forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

'Production' Compilation,Executable&Security Opt. Tips

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> General
View previous topic :: View next topic  
Author Message
John-Silver



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Tue Apr 21, 2020 10:52 pm    Post subject: 'Production' Compilation,Executable&Security Opt. Tips Reply with quote

A 'Production' Compile-Link SECURITY Optimisation Tip
... found hidden in the bowels of the documentation:

While reading up about the various intricacies surrounding all this debugging mularkey (in ClearWin Forum post: 'Extra Checking in Clearwin' http://forums.silverfrost.com/viewtopic.php?t=4192 , in order to better follow the post, I came across this little nugget in the on-line documentation which I hadn't seen before:

Quote:
Runtime tracebacks

SLINK builds an internal map into each executable. The location of this map is registered with SALFLIBC at runtime. It contains the true fixed-up runtime addresses. In the event of a fault during program execution that causes the program to abort, SALFLIBC will print out a traceback of the various routines called, tracing back to the user's main program.

The internal map contains the name and address of all the static and external functions in your code. You may wish (e.g. for code security reasons) to remove this map and forego the run time traceback facility. This may be achieved by using the notrace command.


https://silverfrost.com/ftn95-help/slink/runtime_tracebacks.aspx

.... thus it seems that a good FTN95 programming practice is to make sure you use /NOTRACE for 'production' compilation linking.

****************************************

Repository Suggestion

In the absence of a specific section of the manual gathering together in one such plaice other tips as might optimise (improve) executable runtime, secuity (as he present tip), or other 'good-practices, I'd invite all users to throw their ten-penneth in here on this post as a repository of all similar things they might have come across (just put a highlighted and/or coloured sub-title (as here) at the top of your comment to make it more readily findable for all those young Cpt'n Kirk's (programming where no-one has programmed before, 'n' all that) in the light-years to come.

Users with comments and/or experience(s) of any 'tip' can then start theirs with : RE:- <insert tip comment subtitle here> , as appropriate.
_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... Smile "
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Wed Apr 22, 2020 3:51 am    Post subject: Reply with quote

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 ?
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Fri Apr 24, 2020 9:31 pm    Post subject: Reply with quote

as he (probably) wrote it, I guess Paul's the one to tell us that John.

I can onlyimagine that it relates in some way to commercially released programs.
_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... Smile "
Back to top
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Sat Apr 25, 2020 1:30 pm    Post subject: Reply with quote

Does it make the program run faster as well?

E
Back to top
View user's profile Send private message
Robert



Joined: 29 Nov 2006
Posts: 444
Location: Manchester

PostPosted: Sat Apr 25, 2020 4:28 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message Visit poster's website
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Mon Apr 27, 2020 7:47 am    Post subject: Reply with quote

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!
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Mon Apr 27, 2020 11:15 am    Post subject: Reply with quote

... and it runs slightly against the grain that the production of a traceback is the default and a compile option is required to supress it, surely it should be the other way around.
_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... Smile "
Back to top
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Mon Apr 27, 2020 1:24 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Mon Apr 27, 2020 2:56 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Tue Apr 28, 2020 5:11 pm    Post subject: Reply with quote

Quote:
In such cases, additional instrumentation of the program may be needed to find and fix bugs.


.... ahhhhh ..... "PRINT* is (not)dead ! Long live PRINT*" !!! Smile Smile
_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... Smile "
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> General All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group