> I've also altered my coding style for PalmOS. The style you're
> proposing adds four bytes to the stack for every call - fine in
> general (and it's what I do under Windows), but less advisable
> when you've got 2K of stack. I used to sneer at variables
> defined at block scope until I realised what a difference to stack
> overhead it made.
On current versions of CodeWarrior, defining a variable in an inner
block makes no difference on stack utilization at all. The inner scope
affects accessibilty, but all variable allocation decisions are made at
a function level, not a scope level.
> Hmm, after some testing I found that the following displays the
> problem, but that it seems to be a debugger display issue (and
> the debugger display can't be perfect for optimised code).
>
> UInt16 Blah()
> {
> UInt16 retval = NULL;
>
> if (!mBlahDB)
> {
> retval = NULL;
>
> } else
> {
> retval = mCategory;
> }
> return retval;
> }
>
> The debugger shows no code generated for the central four lines
> of if statement, only the return. Now after sifting through the
assembler
> for this simple function the assembler looks ok so I'm guessing that
> with optimisation on the debugger can't breakpoint on those lines or
> can't connect to them so you don't get the - beside them.
>
> When I step the code above mBlahDB is non-zero but retval remains
> NULL. This is wrong, but the correct value is passed out once I
> exit the function so it looks like the debugger display of retval
isn't
> correct under optimisation. Thank god for that.
The debugger really can't be trusted (except at the assembly level)
above opt 0. CW Palm 8 helps some by showing you what stack address or
register a variable gets assigned, but if optimizations have moves the
value out of a named variable and into a temporary, all bets are off.
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
