storm@cs.mcgill.ca (Marc WANDSCHNEIDER) (04/09/91)
I recently wrote a program that simulates a computer network sending messages
back and forth using heaps, queues, and graphs for routing tables.
I finally got the program working, but the results were kinda screwy. Alas,
I sat there for a few hours ripping my hair out trying to figure out what was
wrong with my program, and came to the conclusion there was none.
Still the program did not work.
I then took another look at the program:
Program Simulator (etc...)
Const etc.
type etc....
Var .....
i: integer; ****** <------ ***********
procedures/functions etc....
begin
....
....
i:= 0;
....
....
....
end.
I then REMOVEd the line i: integer; from the var declarations, and the i:=0;
line from the main program.
Worked fine as soon as I did that.
Anybody know what the hell just happened...? Logic says that it should MAKE
no difference whatsoever that i is there or not, since it is used correctly.
A friend suggested that there were stray pointers, but in PASCAL that shouldn't
be a problem, and the compiler should take care or not allow this.
Any *thoughtful* insight into this problem...? (Okay, so I'm getting a little
sick of "gee, maybe your computer's broken" answers...)
./*-
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
storm@cs.mcgill.ca McGill University It's 11pm, do YOU
Marc Wandschneider Montreal, CANADA know what time it is?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~dmurdoch@watmath.waterloo.edu (Duncan Murdoch) (04/09/91)
In article <1991Apr9.070604.21757@cs.mcgill.ca> storm@cs.mcgill.ca (Marc WANDSCHNEIDER) writes: > >I recently wrote a program that simulates a computer network sending messages >back and forth using heaps, queues, and graphs for routing tables. > >I finally got the program working, but the results were kinda screwy. Alas, >I sat there for a few hours ripping my hair out trying to figure out what was >wrong with my program, and came to the conclusion there was none. ... >I then REMOVEd the line i: integer; from the var declarations, and the i:=0; >line from the main program. > >Worked fine as soon as I did that. > >Anybody know what the hell just happened...? Logic says that it should MAKE >no difference whatsoever that i is there or not, since it is used correctly. > >A friend suggested that there were stray pointers, but in PASCAL that shouldn't >be a problem, and the compiler should take care or not allow this. That's strong evidence that you program's behaviour depends on exactly where it gets loaded in memory. It shouldn't. I'd suspect one (or more) of the following three possibilities: - Stray pointers. Pascal doesn't necessarily protect you from these. For instance, you may try to dereference a pointer after you've dispose'd of it; this might point to something that's good, and might not. You didn't say what Pascal you were using, but if it was TP, then dereferencing disposed pointers is safe for a little while in versions 4 to 5.5, and never safe in the other versions. - Addressing an array out of range. This is only possible if you were running with range checking turned off; in TP, be sure to recompile with $R+ and see if the error persists. - Uninitialized variables. Variables are undefined before you give them a value, so you get all sorts of screwy results if you forget to. There aren't easy solutions to these, but I'd suggest: - Compile with all error checking (i.e. stack and range) turned on - Before running your program, fill memory with a constant value. I've got a program that came with the registered version of A86 that can fill it with the character of your choice; it shouldn't be hard to write one yourself (on a PC; I don't know about other platforms). A good value to use is FFh, because that's very likely to trigger range errors if you have uninitialized variables. It'll also trigger floating point errors if you're using IEEE reals, because a string of FFh's is used to represent NaNs. It's also a good idea to try several different values to see if behaviour depends on what was there before you started. I hope this helps. Duncan Murdoch dmurdoch@watstat.waterloo.edu (sometime) dmurdoch@watmath.waterloo.edu (for now)