> I'm not exactly sure what other subject line to give this problem,
> but it's got me worried.
>
> I've debugged my way down into a module tracing a feature that
> has stopped working and have found that the problem is that a
> function in the form:
>
> MemHandle BlahGetNextItem(UInt16 * Index)
> {
> if (mBlahDB == NULL)
> return NULL;
>
> return DmQueryNextInCategory(mBlahDB, Index, mCategory);
> }
>
> The mBlahDB is a module-level variable defined as:
> DmOpenRef mBlahDB = NULL;
> which is set using an OpenBlahDB function called when the module
> is first accessed.
>
> This function is always returning NULL. In fact, the debugger only
> shows the '-' (showing an 'active' source line) beside the opening
> and closing braces and the 'return NULL' line. The only thing I
> can think of is that the compiler thinks that the test will always
> return true and is dead-stripping the rest of the function. The 'if'
> statement is never being executed.
First, you can't go by debugger ticks to determine what code is
generated. They may server as a guide, but enough stuff can be moved
around in optimized code to make that unreliable.
Second, the CodeWarrior optimizer is NOT smart (or stupid) enough to do
value propogation from a global variable.
> On the other hand the assembler seems to include it (my 15-year
> old memory of assembler suggests that a 'tst.l' followed by a 'bne'
> is a Branch on Not Equal and so would seem to be reasonable
> assembler for an if test against NULL) but the debugger clearly
> shows that variable as non-NULL and yet the test is being acted
> on as if true.
Show us the disassembly. You ought to step through this at the assembly
level with a register window open to see what is really happening.
> This code is in a static library and is compiled with optimisation
> level set to 1. Having noticed this I've set the optimisation level
> to 0 (no deadstripping, among other things) and it seems to have
> fixed the problem (surprising how many things you find while
> carefully explaining the problem to someone else) but I don't see
> how this is valid behaviour for the optimiser.
>
> I've run into this kind of dead-stripping problem before with v6
> and fixed it by forcing a side-effect in the block being dead-stripped
> but seeing the same sort of problem in v7 worries me.
I don't know about these compiler errors, and I can't tell you anything
more about why it is acting right or wrong without a reproducible code
example, or at least a disassembly (see the right-click disassemble
command in the project window).
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
