Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!cmcl2!adm!news
From: CDCKAB%EMUVM1.BITNET@cunyvm.cuny.edu ( Karl Brendel)
Newsgroups: comp.lang.pascal
Subject: Re: SEEKING PROBLEMS ABOUT TURBO PASCAL
Message-ID: <25328@adm.brl.mil>
Date: 21 Dec 90 15:00:40 GMT
Sender: news@adm.brl.mil
Lines: 69

In article <5053@gara.une.oz.au>, ddavidso@gara.une.oz.au (PSYS)
  wrote:

>In article <25323@adm.brl.mil> CDCKAB%EMUVM1.BITNET@cunyvm.cuny.edu ( Karl
> Brendel) writes:
>>In article 9012201616.AA29442@east.gsfc.nasa.gov,
>>  mecklenburg@storm.dnet.nasa.gov (?Rick) wrote:
>>
>>>why, in some programs, does a write or writeln statement sometimes
>>>"fix" a program?  For example, the output of a program may be full
>>>of garbage, or there may be characters missing or whatever, and when
>>>I put in a WRITE or WRITELN statement, it seems like the TP Gods
>>>have waved a magic wand or something and presto!.. the program
>>>works.
>>
>[...deleted...]
>
>>Have you ever tried just recompiling without adding the Write or
>>WriteLn? Writing small programs, I'd bet that you're working within
>>
> [...deleted...]

[...(unfortunately relevant text) deleted...]

>
>>That's almost invariably the result of an uninitialized variable:
>
> [...deleted...]
>
>I don't think that this is always the problem.
>
>I have on occasions had an obscure problem in a program.  In order
>to catch the problem, I've put in a writeln or two, either printing
>out the value of a variable or merely a statement of where the
>program has looped to e.g writeln('At start of procedure xyz').

[...deleted...]

>It generally turns out (after a very frustrating time) that data is
>clobbering code and adding a writeln just adds enough code to lessen
>the damage caused by the clobbering as the position in the code that
>the data clobbers is changed.  Heap errors have also been known to
>cause similar problems.

While you've made a good point, and one I should have made myself,
my "almost invariably" remark was to be considered within the
context of the situation I described and inquired about: "_within
the IDE_, runs once, won't run twice." While that kind of behavior
can be observed when there's a code/data clobbering event occurring
(clobbering data can produce wild results, too--it doesn't have to
be code), it is likely to show up every time the program is run,
unless the affected code/data is only exercised/referenced once:
before the clobbering occurs. While I, too, have so stepped on my
privates (in programming), _every_ time I've seen the "IDE, once not
twice" behavior it has resulted from uninitialized variables.

As an aside for the original poster: Turning range checking on
during development and paying close attention to the limits of the
destination of all Move procedures is very likely to locate the
sources of the errors that PSYS describes. (The range checking will
also help locate variables that need to be initialized--if their
non-initialized state takes them out of their declared ranges.)

+--------------------------------------------------------------------+
| Karl Brendel                           Centers for Disease Control |
| Internet: CDCKAB@EMUVM1.BITNET         Epidemiology Program Office |
| Bitnet: CDCKAB@EMUVM1                  Atlanta, GA, USA            |
|                        Home of Epi Info 5.0                        |
+--------------------------------------------------------------------+