On Wed, 28 Nov 2001, Chris Tutty wrote:
> > MemHandle BlahGetNextItem(UInt16 *Index)
> > {
> > MemHandle result = NULL;
> > // ErrFatalDisplayIf(mBlahDB == NULL, "bullocks, database is not open");
> > if (mBlahDB) result = DmQueryNextInCategory(mBlahDB, Index, mCategory);
> > return result;
> > }
> >
> > try rewriting it.. :) also, if that doesn't work.. uncomment the
> > ErrFatalDisplayIf call :)
> >
> (message rearranged)
> > having multiple returns in a function can confuse the compiler
> > (not to mention it is bad programming) :P
>
> Mmm. Fine for that function but in larger functions doing it your
> way can indent the body of the function off the right margin of the
> page. I generally have a block of validity checks at the start of a
> function with an abort return on failure and then the true body of
> the function with a return at the bottom. Any compiler confused
> by *that* isn't worth what CW7 cost me.
>
> 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.
most return values are 4 byte max :) [either pointer or int]..
so, 4 bytes isn't going to kill the stack so much :) you only
need to do it with the returns..
personally, i think:
int myfunc()
{
if ... return ;
..more code..
if ... return ;
..more code..
if ... return ;
..more code..
return success;
}
can be better rewritten using a goto :)
int myfunc()
{
int result = success;
if ... result = ...; goto myfunc_END;
..more code..
if ... result = ...; goto myfunc_END;
..more code..
if ... result = ...; goto myfunc_END;
..more code..
myfunc_END:
return result;
}
goto's have valid reasons for usage, especially with exception
handling.. one of the best lessons i learn when programming is that
a function should have one entry point (the first {) and one exit
point (the matching }).. surely makes things a hell of a lot easier
to debug sometimes..
> But this is quibbling about coding style and is irrelevant to the
> central question...
true ;)
> > > which is set using an OpenBlahDB function called when the module
> > > is first accessed.
> >
> > 100% sure about this?
>
> Yup. Breakpointed the set and checked the value of the variable again
> when the if statement executes. Even checked the raw memory to
> make sure that the debugger wasn't displaying a value from somewhere
> else.
ok.. sounds like compiler doing too much.. maybe if you dont assign
NULL to the database globally? do that asignment in the initialization?
the compiler could be treating it as a "oh, he has set it, its a
constant maybe" and is then subsequently removing that chunk of code?
> > > 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'
> >
> > 15-year old? hehe.. he's just perfect for the warez group! :)
> > [for all you know, maybe he is] :P
>
> No, I'm not fifteen. It's been fifteen years since I last coded in
> assembler (roughly).
oops.. i read that as your 15-year old suggests :) hehe
> 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.
>
> OK, ok, move along. Panic over. Nothing to see here folks.
:) maybe you should try removing the = NULL; assignment globally :P
some compilers try to be too smart.. i have had problems with
codewarrior removing functions from the linking process cause they
were not called directly.. this was a problem cause i was doing my
own segment loading/switching ;)
nice thought for compiler tho, but, had to write a few lines of
code to "dummy" use it so my technique would work :) drove me crazy,
and its one of the reasons i love prc-tools :)
// az
[EMAIL PROTECTED]
http://www.ardiri.com/
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
