siegel@endor.uucp (Rich Siegel) (11/17/90)
In article <1990Oct27.074058.10748@agate.berkeley.edu> physi-hf@garnet.berkeley.edu (Howard Haruo Fukuda) writes: >Poking around with Macsbug, I've found out that, Think C has put some of my >global variables for a DA at an odd numbered address. It then tries to copy >I guess as a last resort, I could rewrite it for MPW C, but I would like to >hear any more elegant solutions, especially since MPW C doesn't support global >variables in a DA like Think C does. Last Resorts aren't necessary here. Instead, take care that all of your strings are aligned on word boundaries. I'm not 100% sure, but I believe that this will ameliorate the problem. >Or does anyone have Symantic's Tech support number? My manual is still trying >to catch up to me via US mail. The Symantec (no "i" in Symantec) support number for languages is 617-275-4800. R. Rich Siegel Symantec Languages Group Internet: siegel@endor.harvard.edu "...she's dressed in yellow, she says 'Hello, come sit next to me, you fine fellow..."
physi-hf@garnet.berkeley.edu (Howard Haruo Fukuda) (11/18/90)
In article <4742@husc6.harvard.edu> siegel@endor.UUCP (Rich Siegel) writes: >In article <1990Oct27.074058.10748@agate.berkeley.edu> physi-hf@garnet.berkeley.edu (Howard Haruo Fukuda) writes: > >>Poking around with Macsbug, I've found out that, Think C has put some of my >>global variables for a DA at an odd numbered address. It then tries to copy > >>I guess as a last resort, I could rewrite it for MPW C, but I would like to >>hear any more elegant solutions, especially since MPW C doesn't support global >>variables in a DA like Think C does. > > Last Resorts aren't necessary here. Instead, take care that all of >your strings are aligned on word boundaries. I'm not 100% sure, but I believe >that this will ameliorate the problem. I'm not sure I understand your response. My problem was that Think C was not putting my strings on word boundaries. The line: Str255="\pHuh???"; places the pascal string at an odd-numbered address (well, not neccessarily all the time). For some reason changing the line to: static Str255="\pHuh???"; does put the string on a word boundary. (Thanks to Steve Martin for telling about the above hack.) Why does this work? -Howard
phils@chaos.cs.brandeis.edu (Phil Shapiro) (11/20/90)
In article <1990Nov18.070105.20735@agate.berkeley.edu> physi-hf@garnet.berkeley.edu (Howard Haruo Fukuda) writes: I'm not sure I understand your response. My problem was that Think C was not putting my strings on word boundaries. The line: Str255="\pHuh???"; places the pascal string at an odd-numbered address (well, not neccessarily all the time). For some reason changing the line to: static Str255="\pHuh???"; does put the string on a word boundary. (Thanks to Steve Martin for telling about the above hack.) Why does this work? First, using "static" is not a solution, since globals may be odd aligned in the same way that locals are. Try: main() { static char c; static Str255 s; } and look at &c and &s in the debugger. The fact is, Think C only word aligns your data if it is necessary. The reason that Str255's do not necessarily have to be word aligned is that all 680x0 machines allow odd address when accessing byte-sized data. That is, a "MOVE.B (Ax), xxx" will never fail. So, if your strings are used for accessing characters you're all set. If, however, you declare a Str255 and then cast it into an integer pointer, you're asking for trouble. The answer is (as Rich said) to make sure that your strings are word aligned if you need it. This can be accomplished by declaring an int or long just before the string, or by always using NewPtr() to allocate string storage. The last time this came up, somebody mentioned some Toolbox routines that expect word aligned strings (like SetIText?). Does anybody have a list? -phil -- Phil Shapiro Technical Support Analyst Language Products Group Symantec Corporation Internet: phils@chaos.cs.brandeis.edu
gt0657c@prism.gatech.EDU (geoff george) (11/20/90)
This thread has discussed odd addresses of char and string variables,
which can be worked around by rearranging declarations. THINK C has
done worse to one of my programs. It put the initial value for an
Str255 at an odd address (NOT the Str255; its initial value) which
makes the initialization code that TC uses blow up with an Address
Error on 68000 Macs. (It runs fine on my Mac II, and on a 68020-
enhanced Mac Plus at work.)
My routine starts as follows:
static void DoMenu (long itemCode)
{
int menuID = HiWord (itemCode);
int itemID = LoWord (itemCode);
Str255 DAName = "\p"; <-- problem
long drvr = 'DRVR';
...
and MacsBug disassembly shows the following code being used to
initialize the Str255 DAName with a zero-length value, after setting up
the stack frame and initializing the two preceeding ints:
...
LEA -$0104(A6), A0
LEA -$1137(A5), A1 <-- odd offset; patently wrong
MOVEQ #$3F, D0
MOVE.L (A1)+, (A0)+ <-- blows up
DBF D0, <the MOVE.L instruction>
...
How do I go about submitting a bug report to Symantec, and what can I
expect in the way of response? I understand that this is a known bug,
at least among some TC users.
geoff
--
geoff george geoff@remvax.gatech.edu (my vax)
or gt0657c@prism.gatech.edu (a touch of warmth from GaTech OCS)
"Ordinary f---ing people - I hate 'em. Ordinary person spends his life avoiding tense situations; repo man spends his life getting INTO tense situations."physi-hf@garnet.berkeley.edu (Howard Haruo Fukuda) (11/20/90)
In article <PHILS.90Nov19151704@chaos.cs.brandeis.edu> phils@chaos.cs.brandeis.edu (Phil Shapiro) writes: >The fact is, Think C only word aligns your data if it is necessary. >The reason that Str255's do not necessarily have to be word aligned is >that all 680x0 machines allow odd address when accessing byte-sized >data. That is, a "MOVE.B (Ax), xxx" will never fail. > >So, if your strings are used for accessing characters you're all set. >If, however, you declare a Str255 and then cast it into an integer >pointer, you're asking for trouble. The problem was that when I declared the string in a function: Str255="\pThis is a string"; the pascal string was at an odd address (among the global variables). When the function was entered, space was allocated on the stack for the string, and then Think C tried to copy to data from where the string was in global to the space allocated on the stack with a MOVE.L/DBF loop. This caused a bus error. There were no funny casts involved or anything. The string declaration is the only thing that gets executed before the bus error halts execution. My point is that this is a perfectly valid statement in C and that the error is caused (in MHO) by the compiler. -Howard
Chris.Gehlker@p12.f56.n114.z1.fidonet.org (Chris Gehlker) (11/22/90)
physi-hf@garnet.berkeley.edu (Howard Haruo Fukuda) writes: > >>Poking around with Macsbug, I've found out that, Think C has put some of my > >>global variables for a DA at an odd numbered address. It then tries to copy > > > >>I guess as a last resort, I could rewrite it for MPW C, but I would like to > >>hear any more elegant solutions, especially since MPW C doesn't support > global >>variables in a DA like Think C does. THINK C defines str255 as: typedef unsigned char Str255[256]; I can't see why this shouldn't start at an odd address. BTW you can use globals in MPW. Check out TN 256. -- Uucp: ...{gatech,ames,rutgers}!ncar!asuvax!stjhmc!56.12!Chris.Gehlker Internet: Chris.Gehlker@p12.f56.n114.z1.fidonet.org