phils@chaos.cs.brandeis.edu (Phil Shapiro) (02/13/91)
In article <1668@tcs.tcs.com> pbuck@tcs.com (Peter Buckner) writes:
Summary: Think C illegally permits automatic initialization of aggregates,
and then generates wrong code for it.
1/4 right. Really, Think C generates the correct code, for a legal
ANSI C construction, but since it isn't documented that it uses A4, it
crashes miserably. More later.
The trick is how you create your own pattern. If you do:
Pattern myGray = {0x55, 0xaa, 0x55, 0xaa, 0x55, 0xaa, 0x55,
0xaa};
where myGray is a GLOBAL variable, the initialization succeeds, and
the pattern is defined correctly (except, I don't think you can use
global variables in WDEFs, so this works only in applications, not
code resources).
You can have globals in THINK C code resources, they are simply
referenced off of A4.
If you write the same statement, with the initialization, as a
LOCAL variable declaration, then you are doing what is called by
K&R "automatic initialization of an aggregate (array or struc)"
which is not permitted. Other compilers spit it out as an error.
You're looking at an aged copy of K&R. Check out the 2nd edition
copy, page 86. It's supported under ANSI.
*Think C does not*. To make matters worse, if you do such an
initialization in an application, it appears to work just fine.
However, in a code resource, "myGray" ends up with garbage
(possibly a relative to the A5 problem?)
It generates OK code, but it assumes that A4 is pointing to your
global space. If you use RememberA0()/SetUpA4(), then your
initialization will work fine. The reason this initialization works
for globals is because, unlike automatic allocation, the initial
values are stored directly into the code resource itself. No
initialization occurs at runtime.
-phil
--
Phil Shapiro Technical Support Analyst
Language Products Group Symantec Corporation
Internet: phils@chaos.cs.brandeis.edu