m0p@k.cc.purdue.edu (S. Kulikowski) (12/27/88)
am i crazy, or am i the only one who has trouble with Turbo Pascal pointers?
any pointers about TP pointers?
with TP3 i had about half a dozen projects going which just stopped dead in
their tracks when the pointers started returning garbage. these were
procedures (and functions) which were well formed syntactically and even
debugged until the program got to about 5000 lines in length. i know how to
check MEMAVAIL and it reported plenty of memory free, but when programs got to
a certain level of complexity, somewhere in ACM CS-2 level curriculum, things
ran aground in the sea of memory trash. (i used to teach ACM CS-1 courses.)
the pointers just went gaga into nowhereland. no runtime error about stack or
heap collision, all the memory allocations appeared to have plenty of room:
just garbage.
last year i got TP4 real early, but took some time before around to
recompiling the pointer-intensive projects. things started working again. but
not for long.
last week, i was working on a project (for work this time) on am IBM PS/2
model 30 and the TP4 pointers started returning garbage when earlier they had
been returning the the right values. really looks familiar. i had to scrap
the whole pointer section of code and substitue a clumsy method which copies
the data into a local file then adds new data on the end of each line from the
data file. still doesn't work perfect, bit at least the first two passes
through the data returns values instead of garbage. with the pointers, the
PS/2 was really freaking out, apparently displaying ROM memory garbage:
sometimes exotic characters and colors, sometimes fragments of weird error
messages about BASIC (eg-- 'NEXT WITHOUT FOR STATEMENT','GOTO OUT OF RANGE',and
so on.) this is a moderately complicated program (only ~6000 lines of code
now), marking and releasing NEW-made pointers to variable data read in from
files, depending on how the user uses the program. MEMAVAIL says about 330K
free memory left.
now i have a pointer-intensive program (1585 lines, TP4 MEMAVAIL reports
655,530 bytes free at runtime) which won't backup a double-linked list of
pointers. this is done on 853K DEC Rainbow with TP4 running with command-line
TPC mode.
this has happened on enough different programs of different complexity
levels, that it is unlikely to be something wrong in the specific code. when
procedures start returning garbage, which used to work correctly, you know
something is wrong. any ideas on what to check for? how can i force the
compiler to return the right pointer locations? any recommendations on a
generic MSDOS PASCAL compiler which can keep track of its pointers?
stan
BITNET : XM0P @ PURCCVM (* note, zero, not Oh *)
SnailMail : Special Education; Purdue University; W. Lafayette, IN 47907
USENET : k.cc.purdue.edu!m0p COMPUSERVE : 75410,1211wilker@batcomputer.tn.cornell.edu (Clarence W. Wilkerson Jr.) (12/27/88)
I have written lots of lines of code with TP 2,3,4 and just started with tp 5. I've used pointers extensively, and the only time I've gotten nonsense is when I've screwed up.
marty@june.cs.washington.edu (Marty Sirkin) (12/28/88)
I don't know if this helps, but I have written well over 100,000 lines of TP programs (3.0, 4.0 and 5.0) and have NEVER had any pointer problems that were not of my own creation. I have seen many cases (mainly from teaching/grading) where pointer routines will have a subtle bug which works correctly some times/in some cases, but not always. Sounds like what you have. Perhaps (if it is short enough) you should post (or E-mail - I'll be happy to take a look) the pointer routines from the program you mention. If the whole program is 1500 lines, the pointer routines shouldn't be too long. Marty Sirkin
ncsmith@ndsuvax.UUCP (Timothy Smith) (01/02/89)
reply to S. Kulikowski on Turbo pascal pointers:
I have found the pointers in TP3 - TP5 to works reliably and just
how I tell them to. Now barring any non-obvious errors in the pointer
code I have found the biggest area where problems can occur in pointer
intensive code is around declared arrays. No version of TP defaults to
checking the range of a subscript for an array so if you declare a
pointer variable after an array and access a cell that exceeds
the upper bound on the array your pointer could be trashed. Of course
anything else after it could be trashed including code if the subscript
is right. So rather than bash the complier, check out your array code.
--
Tim Smith North Dakota State University, Fargo, ND 58105
UUCP: ...!uunet!ndsuvax!ncsmith | 90% of the people on this planet
BITNET: ncsmith@ndsuvax.bitnet | are crazy and the rest of us are
INTERNET: ncsmith@plains.NoDak.edu | in grave danger of contamination
#! rnews mitch@arcturus.UUCP (Mitchell S. Gorman) (01/04/89)
In article <7071@batcomputer.tn.cornell.edu>, wilker@batcomputer.tn.cornell.edu (Clarence W. Wilkerson Jr.) writes: > > I have written lots of lines of code with TP 2,3,4 and just started > with tp 5. I've used pointers extensively, and the only time I've > gotten nonsense is when I've screwed up. Yeah, same with me. The only thing I haven't been able to get running under TP4.0 are my keyboard-interrupt TSRs. (Damn that nearly-nonex- istant interrupt procedure documentation!! :^) At the risk of stating the stupidly obvious (one of my favorite things to do BTW!), have you run UPGRADE on these suckers?? That will tell you whether or not you're using such functions as CSEG, et al, to get what you're actually looking for. At least it prints out a nice-sound- ing little message about it anyway! Mitch @ Rockwell, Anaheim
ncsmith@ndsuvax.UUCP (Timothy Smith) (01/05/89)
reply to S. Kulikowski on Turbo pascal pointers:
I have found the pointers in TP3 - TP5 to works reliably and just
how I tell them to. Now barring any non-obvious errors in the pointer
code I have found the biggest area where problems can occur in pointer
intensive code is around declared arrays. No version of TP defaults to
checking the range of a subscript for an array so if you declare a
pointer variable after an array and access a cell that exceeds
the upper bound on the array your pointer could be trashed. Of course
anything else after it could be trashed including code if the subscript
is right. So rather than bash the complier, check out your array code.
ps: this is a second sending as the first got mauled somewhere around
rutgers.
--
Tim Smith North Dakota State University, Fargo, ND 58105
UUCP: ...!uunet!ndsuvax!ncsmith | 90% of the people on this planet
BITNET: ncsmith@ndsuvax.bitnet | are crazy and the rest of us are
INTERNET: ncsmith@plains.NoDak.edu | in grave danger of contamination