replica nfl jerseysreplica nfl jerseyssoccer jerseyreplica nfl jerseys forums.silverfrost.com :: View topic - Pure devilry catch in debugger
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 

Pure devilry catch in debugger

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> 64-bit
View previous topic :: View next topic  
Author Message
DanRRight



Joined: 10 Mar 2008
Posts: 2923
Location: South Pole, Antarctica

PostPosted: Sat May 05, 2018 2:48 am    Post subject: Pure devilry catch in debugger Reply with quote

Look at this snapshot. By unimaginable way the SDBG64 succeeded to miss the first red line and stopped only at the second absolutely identical one with the undefined error message.



UPDATE:
i saved the code, double checked that the bug is 100% reproduced but when returned later again the bug disappeared. Double devilry?

Such happened decades ago as indication that i need to reboot computer. Anyone else saw such behavior with unexplainable errors?


Last edited by DanRRight on Sat May 05, 2018 3:29 am; edited 1 time in total
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1899

PostPosted: Sat May 05, 2018 3:09 am    Post subject: Reply with quote

If kPlot_Ee_Center is 1 and kPlot_Ei_center is undefined, what the compiled code did is quite reasonable. Given an expression (L1 .and. L2), where L1 is false, L2 need not be evaluated to know that (L1 .and. L2) is false; thus, the problem that L2 may depend on undefined variables may not be detected.

The F95 standard has this to say:
Quote:
7.1.7.1 Evaluation of operands
It is not necessary for a processor to evaluate all of the operands of an expression, or to evaluate entirely each operand, if the value of the expression can be determined otherwise.


As a general rule, compilers that support detecting undefined variables do not flag the mere presence of such variables; only when one of these variables is used (or queried in the debugger). Otherwise, all of the program memory would have to be checked frequently, and that would consume too much time.
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2923
Location: South Pole, Antarctica

PostPosted: Sat May 05, 2018 3:15 am    Post subject: Reply with quote

You are probably right, mecej4.

Devilry escaped Smile
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1899

PostPosted: Mon May 14, 2018 6:52 am    Post subject: Reply with quote

Checking input data should include checking that data is input AND that the input values are correct. If a program uses undefined variables, those are variables that should have been given values earlier, by assignment or a READ statement but, because of programmer error, have been left undefined.

Consider a program that solves a quadratic equation A x^2+B x + C = 0. By mistake, the program does READ *, A,B; as a result, the program uses C without defining it. If you only check that A and B have correct values, and do not notice that C has been left out of the READ statement, you would find that running the program with the same values of A and B gives a different set of results from run to run, and the program may even crash sometimes.


Last edited by mecej4 on Mon May 14, 2018 11:08 am; edited 1 time in total
Back to top
View user's profile Send private message
LitusSaxonicum



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

PostPosted: Mon May 14, 2018 10:15 am    Post subject: Reply with quote

I'd add to the above a check that the input data is actually input data for the program in question, and the correct version.

If the data file starts with something like:

'DannyBhoy version 39.01'

You can check that it is data for DannyBhoy.exe, but also it may not be compatible with an earlier version of the program, e.g. from version 32.00 the program may expect more or different data. In my case, such a change was adding the RGB values for all the material types, rather than letting the program decide.

It is a considerable annoyance to me that recent versions of my favourite, CorelDRAW!, won't read old files. However, you can fix this by having the appropriate version-dependent input facilities, then you can read old files.

In Mecej4's example, even if C has been initialised, you get the same answer every time, just that mostly they are wrong (in the sense that they aren't what the user expects). The program delivers the correct answer - maybe - to the problem given).

Sometimes too aggressive a check on data values can inhibit the use of the program. For example, checking that the unit weight of rock or soil is greater than 15 kN/m^3 stops you using the program on the moon or Mars, and even if earthbound, prevents you analysing problems involving peat or lightweight fills.

Eddie
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 -> 64-bit 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