qingzhou@phoenix.Princeton.EDU (Qing Zhou) (12/20/90)
I am writing a book "Turbo Pascal 5.5: Tips, Traps and Tricks". This book will contain about a hundread topics divided into several categories. Each topic is one to three pages long. While a large part of this book will be based on my own experiences, I am also considering collect small problems from the netters. So here is the deal: If you have any problem with Turbo Pascal which you can not solve, please mail it to me, explaining the problem clearly and concisely. I GUARANTEE to reply to EVERY question even in case I don't ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ have a definte solution. Please tell your friends who don't read this newsgroup but might benifit from it. Send all questions to: qingzhou@phoenix.princeton.edu. Please make the subject as: TP QUESTION. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Some requirements: (1) Each question should not exceed 50 lines. (2) If you include a demo source code, the code should not exceed 100 lines. (3) Please put your returning email address inside your mail, as I will not save the header of the mail. I will post some of those questions which I think will be of common interest.
mecklenburg@storm.dnet.nasa.gov (12/21/90)
I am a fairly recent member of this bulletin board, and because I am
only a sophomore at the University of Alabama in Huntsville, my computer
programs I write in TP5.5 are usually less than 750 lines. My question is:
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. This is something I have
not seen addressed in this board, but it's probably a silly question. Try
not to laugh to hard.
Thanks, Rick
CDCKAB%EMUVM1.BITNET@cunyvm.cuny.edu ( Karl Brendel) (12/21/90)
In article 9012201616.AA29442@east.gsfc.nasa.gov, mecklenburg@storm.dnet.nasa.gov (?Rick) wrote: >[...deleted...] > >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 the IDE and compiling to memory. I'd also bet that on these occasions you note, that the program works right after you compile it to and execute it from memory, then you get the garbage on the second or subsequent run if you don't recompile in the meantime. That's almost invariably the result of an uninitialized variable: TPas inits variables (not "typed constants") to 0 when it compiles, but on a subsequent run (without recompilation), you can get all kinds of garbage in the variables. If recompilation doesn't fix the problem, could you post some _brief_ code illustrating a situation like you're talking about, and describe your compiling/executing environment (IDE or TPC, etc.)? +--------------------------------------------------------------------+ | 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 | +--------------------------------------------------------------------+
ddavidso@gara.une.oz.au ( PSYS) (12/21/90)
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...] >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'). Its often at this point that Murphys Law (or is it Heisenberg's Principle of Uncertaintity) comes into play. Adding the writeln to the program fixes the bug! Removing the writeln lets the bug show its ugly head again! 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.
abcscnuk@Twg-S5.uucp (Naoto Kimura (ACM)) (12/21/90)
One BIG problem for most beginners is that Turbo Pascal has
range-checking turned off by default. In installing Turbo Pascal here
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
at CSUN, I made sure that it got installed with the range-checking
turned on.
The thing that I find too bad about this is that the very people who
need to have range-checking turned on are those who are first-timers
and didn't know what this does, nor would know that they had to turn it
on. One person I knew spent two weeks tracking down an array index out
of range error. After informing him about the array bounds checking,
the problem became immediately apparent.
Another person I knew got screwed over by his partners when they
***EXPLICITY TURNED IT OFF***. After getting rid of the compiler
directive, the problem showed up in part of the initialization code
that his partners wrote. It was full of unititialized variables and
unreasonable assumptions -- which were "fixed" by turning off the
range-checking.
//-n-\\ Naoto Kimura
_____---=======---_____ (abcscnuk@csuna.csun.edu)
====____\ /.. ..\ /____====
// ---\__O__/--- \\ Enterprise... Surrender or we'll
\_\ /_/ send back your *&^$% tribbles !!CDCKAB%EMUVM1.BITNET@cunyvm.cuny.edu ( Karl Brendel) (12/21/90)
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 | +--------------------------------------------------------------------+
CDCKAB%EMUVM1.BITNET@cunyvm.cuny.edu ( Karl Brendel) (12/21/90)
In article <1990Dec21.045802.16278@csun.edu>, abcscnuk@twg-s5.uucp (Naoto Kimura (ACM) wrote: >One BIG problem for most beginners is that Turbo Pascal has >range-checking turned off by default. In installing Turbo Pascal >^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >here at CSUN, I made sure that it got installed with the >range-checking turned on. > >The thing that I find too bad about this is that the very people who >need to have range-checking turned on are those who are first-timers >and didn't know what this does, nor would know that they had to turn >it on. One person I knew spent two weeks tracking down an array >index out [...remainder deleted] How true, how true--but just think what TPas would look like in comparitive reviews of code size, when the reviewers chose (as they sometimes do) to accept the compiler defaults! And if they were C fanatics, they might even do, "When we set MS C 10.0 and Watcom C 16.0 for full optimization, the difference was even clearer. (MS C was run with the switch settings -0x$%9dslk290, Watcom with -%%#xzo+*&d45. Since Turbo Pascal 6.0 is not truly an optimizing compiler, we didn't change its switch settings.)" <wry grin> +--------------------------------------------------------------------+ | 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 | +--------------------------------------------------------------------+