david@swift.cs.tcd.ie (01/12/91)
I have just purchased a new version of THINK Pascal to run on a Mac II si,
and have encountered two problems when dealing with PACKED ARRAYs of BOOLEAN.
i. The mapping for the elements of "A: PACKED ARRAY [0..7] OF BOOLEAN" is
not the same as the mapping for "B: PACKED ARRAY [1..8] OF BOOLEAN"
If A and B are viewed as bytes, then
setting A[0]:=TRUE corresponds to setting the byte value to 1,
...
setting A[6]:=TRUE corresponds to setting the byte value to 64, and
setting A[7]:=TRUE corresponds to setting the byte value to 128
while
setting B[1]:=TRUE corresponds to setting the byte value to 2,
...
setting B[7]:=TRUE corresponds to setting the byte value to 128, and
setting B[8]:=TRUE corresponds to setting the byte value to 1
yet the manual states that the elements of a packed data structure are
allocated sequentially
ii. Assigning a boolean value based on the comparison of elements from packed
boolean data structures, will not always produce the correct result
Given the declarations
VAR
RESULT: BOOLEAN;
LOGICAL1,LOGICAL2: PACKED ARRAY[0..7] OF BOOLEAN;
the statement
RESULT:=LOGICAL1[3]=LOGICAL2[3];
will produce the following results
LOGICAL[1] LOGICAL[2] RESULT
---------- ---------- ------
TRUE TRUE TRUE
TRUE FALSE TRUE !!!
FALSE TRUE FALSE
FALSE FALSE TRUE
This problem can be solved by using an if statement
IF LOGICAL1[3] = LOGICAL2[3]
THEN RESULT:=TRUE
ELSE RESULT:=FALSE;
I would like to know if I am missing something obvious, if there are any other
known problems in this area, etc.
David M. Abrahamson,
Dept. of Computer Science,
Trinity College, Dublin 2, Ireland.
E-Mail to David@CS.TCD.IELewis_P@cc.curtin.edu.au (Peter Lewis) (01/15/91)
In article <1991Jan11.190458.7714@swift.cs.tcd.ie>, david@swift.cs.tcd.ie writes: > I have just purchased a new version of THINK Pascal to run on a Mac II si, > and have encountered two problems when dealing with PACKED ARRAYs of BOOLEAN. > > setting A[0]:=TRUE corresponds to setting the byte value to 1, > ... > setting B[1]:=TRUE corresponds to setting the byte value to 2, Certainly does seem that way > ii. Assigning a boolean value based on the comparison of elements from packed > boolean data structures, will not always produce the correct result > VAR > RESULT: BOOLEAN; > LOGICAL1,LOGICAL2: PACKED ARRAY[0..7] OF BOOLEAN; > > RESULT:=LOGICAL1[3]=LOGICAL2[3]; > will produce the following results > LOGICAL[1] LOGICAL[2] RESULT > ---------- ---------- ------ > TRUE TRUE TRUE > TRUE FALSE TRUE !!! > FALSE TRUE FALSE > FALSE FALSE TRUE In fact, there is no problem with this assignment. The problem stems from the fact that the following code bool:=false; logical1[3]:=bool; does not work. In fact it clears a bit far away from logical1. The code generates this - CLR.B D6 ; bool:=false; MOVEQ #$03,D0 MOVE.W D0,D1 LSR.W #$3,D1 ; offset in bytes from the start of logical1 TST.B D6 BEQ.S ClrIt ADDI.W #-$108,D1 ; Ooops! BSET D0,$00(A5,D1.W) BRA.S Finish ClrIt BCLR D0,$00(A5,D1.W) ; where is the corresponding ADDI Finish So assigning a boolean variable to logical1[3] will work fine if the variable is true, but will fail if the boolean is false. > This problem can be solved by using an if statement > > IF LOGICAL1[3] = LOGICAL2[3] > THEN RESULT:=TRUE > ELSE RESULT:=FALSE; I suspect when you tested this, you put "LOGICAL1[3]:=true" and not for bool:=false to true do begin logical3[3]:=bool; as you probably did for the truth table. > I would like to know if I am missing something obvious, if there are any other > known problems in this area, etc. The only related problem I know of, is that this code - const s = 'hello'; begin writeln(s[2]); { will print random stuff } end. will fail if range checking is on. > David M. Abrahamson, > Dept. of Computer Science, > Trinity College, Dublin 2, Ireland. I suggest you leave packed arrays of booleans alone unless you are very careful! Fun fun fun, Peter. -- Disclaimer:Curtin & I have an agreement:Neither of us listen to either of us. *-------+---------+---------+---------+---------+---------+---------+-------* Internet: Lewis_P@cc.curtin.edu.au I Peter Lewis ACSnet: Lewis_P@cc.cut.oz.au I NCRPDA, Curtin University Bitnet: Lewis_P%cc.curtin.edu.au@cunyvm.bitnet I GPO Box U1987 UUCP: uunet!munnari.oz!cc.curtin.edu.au!Lewis_P I Perth, WA, 6001, AUSTRALIA Hack: ResEdit ResEdit 2.0b2, change CODE=5, 00091C: 4EBA 02A4 to 4E71 4E71
legg@ucs.adelaide.edu.au (Christian Legg) (01/17/91)
From article <1991Jan11.190458.7714@swift.cs.tcd.ie>,
by david@swift.cs.tcd.ie:
[Lots of problems with Binary data structures in Think Pascal...]
Think Pascal 3.0 has a few bugs in it when it comes to handling binary
data structures, particularly packed ones. The fix for this is to obtain
the Think Pascal 3.01 updater, posted a few months back on comp.binaries.mac.
cheers
christian leggbloks@ebm.eb.ele.tue.nl (rudi_bloks) (01/23/91)
About the following error with THINK pascal 3.0 (And also 3.01): > I'm having a problem with Think Pascal that is wasting a lot of my time. > Every so often when I select "Go" from the "Run" menu instead of my > program executing, an alert with 3 lines of garbage text gets displayed. > After hitting the OK button, a "Think Pascal has unexpectedly quit" > alert appears. I have no idea what's going wrong. I don't think my > programs are the cause. Has anyone had similar problems or is it just > me? > I'm using a IIsi with 5 megs of ram. System 6.0.7. It's happened under > Finder and Multifinder. I have encountered exactly the same problem with THINK pascal 3.01. Also, i have found a 95% guaranteed way of reproducing it. So for those of you that never saw it, and Symantec in particular, here it is: 1) Run TP under MultiFinder and allocate x Kb of memory. Choose x yourself, i have allocated 2500 Kb to TP. 2) Open any project file, choose run options and set the amount of run time memory allocated to your project to any value larger than x. I set it to 3500 Kb. 3) Choose 'GO'. Result: TP crashes, by showing a large dialog box filled with a few lines of garbage (random) characters, where you are required to click 'OK'. After doing so, it crashes with ID = 3. (unexpectedly quit error message displayed by MF). Apparently, TP doesn't check if it has enough memory to allocate to your project. IT just goes ahead as if it *does* have anough. Now that we're talking about TP anyway, here's some more strange behavior: * If you define a PACKED ARRAY[0..32767] OF BYTE, and also a pointer to it, then something goes wrong with computing the address of any indexed location of the array, if the index is anything but a constant. The following program crashes with a bus error. program test; type ByteArray = packed array[0..32767] of Byte; BArrPtr = ^ByteArray; var rom: BArrPtr; ind: Integer; begin rom := BArrPtr(NewPtr(100)); for ind := 0 to 99 do rom^[ind] := 99 - ind; ind := 10; writeln(rom^[ind]); end. This only happens with the debugging option ON. If either of the two index range values in the type definition is changed, the bug disappears, even if the size of the array type stays the same. Checking out the array addresses with the OBSERVE window reveals that the array locations are computed incorrectly. * When your program is stopped in the debug mode, TP changes the updateRgn of your app's windows to something of its own, and sets them back when your app. resumes execution. However, if you try to examine this updateRgn using LightsBug, you get to see the values that TP put in there i.s.o. your own. Only typing the corresponding expressions in the observe window will reveal the real updateRgn for your application windows. Rudi. ====================================================================== | Rudi Bloks | email bloks@eb.ele.tue.nl | | Eindhoven University | elebrb@urc.tue.nl | | Of Technology ================================== | Dept. Of Electrical Engineering, EH 11.29 | | POBox 513, 5600 MB Eindhoven, the Netherlands | ======================================================================
cfranz@iiic.ethz.ch (Christian Steffen Ove Franz) (06/19/91)
Sorry if this is a FAQ... I'm having problems using the FixMath libs. Although I include both interface and library file into my project, the compiler generates a link-error for the routines Fix2X and X2Fix. Anyone any ideas? oh, yes, anotherone has left me puzzled: what is the correct format to call the ScrollRect() proc? The compiler insists that this is a function... Or is this the proc i *have* to use the alternate format (top,lft,bot,rgt)? please email. thanks in advance, christian. ----------------------------------------------------------------------------- Christian S. O. Franz | cfranz@iiic.ethz.ch ETH Zuerich, Swizerland | vismgr@rz.ethz.ch