Aaron Ardiri wrote:
>
> maybe the "string" you are copying is barfing the stack somewhere?
>
> 'i' = 105 = 0x69
>
> you maybe corrupting the stack somewhere, and, as a result.. corrupting
> the "program counter".. and wola.. try storing your string in a resource
> instead of as a "local" object in the application..
>
> you are messing with too much memory, and it just cannot handle it.
>
> if you changed yout string to "jjjjjjjjjjjjjjjjjjjjj", then i bet your
> error would be "0x70707070" :P - just a small hunch i have :)) try it.
> PilRC allows you to create a string resource, and you should be able to
> do the same in the Code Warrior environment.
>
> [EMAIL PROTECTED]
Thanks guys. Silly me, I should have known where that 0x69 was coming
from. Actually, changing the string to "jjjjjjjjjjjjjj" gives 0x6A, not
0x70 -- it's hex, after all.
When I pull the string out of the function and put it in a string
resource or a global const char array, the error goes away. I suppose
string resources are preferable to global const char arrays because the
latter uses up heap space but the former does not?
Global const char arrays are a bit more convenient because I have a
number of strings I need to concatenate together at runtime, like this:
// at top of file
const char *stringbase = "base ";
const char *stringA = "alpha ";
const char *stringB = "beta ";
const char *stringC = "gamma";
// inside my function
StrCopy(sendStr, stringbase);
if (something == true)
StrCat(sendStr, stringA);
else
StrCat(sendStr, stringB);
StrCat(sendStr, stringC);
But if I were to use string resources I'd have to do something like
this:
// in rcp file
STRINGTABLE ID myStringTable "base " "alpha " "beta " "gamma"
// in function
SysStringByIndex(myStringTable, 0, sendStr, sizeof(sendStr));
if (something == true)
SysStringByIndex(myStringTable, 1, tempStr, sizeof(tempStr));
else
SysStringByIndex(myStringTable, 2, tempStr, sizeof(tempStr));
StrCat(sendStr, tempStr);
SysStringByIndex(myStringTable, 3, tempStr, sizeof(tempStr));
StrCat(sendStr, tempStr);
which involves a bit more runtime overhead. So, is it better in
principle to sacrifice speed for memory?
"Scott Johnson (Bellevue)" wrote:
>
> Yes, it looks like a long string of i's is overwriting the stack. But your
> code seems to be safely copying all those i's into a heap chunk where it
> can't hurt the stack. But what about that printf call?
>
> Now where did this printf function come from anyway? Did you write it
> yourself, or is this the StdIOPalm.c module from Palm? If the latter, where
> did you get it? (I can't find the StdIO source files anywhere!) Either
> way, look in the code for any unsafe buffer size assumptions that could lead
> to this kind of bug.
>
> -slj-
Funny thing, that. I originally coded for Linux, using printfs for
debugging purposes. When I ported to Palm, I just left the printfs in
the code and the compiler didn't complain even though I wasn't including
the UNIX stdio.h. On a Palm, the printf just dumps a string onto the
screen without regard to your application's UI. printf has been a good
debugging tool up until now.
I tried to find the declaration for printf in the Palm SDK header files,
but it's not there. However, it is in the PRC-Tools m68k-palmos
directory:
satang@aurum:/usr/local/m68k-palmos> find . |xargs grep printf
Binary file ./bin/nm matches
Binary file ./bin/strip matches
Binary file ./bin/ar matches
Binary file ./bin/ranlib matches
Binary file ./bin/as matches
Binary file ./bin/ld matches
Binary file ./bin/gcc matches
Binary file ./lib/libc.a matches
Binary file ./lib/libg.a matches
Binary file ./lib/libmf.a matches
Binary file ./lib/libm.a matches
./include/stdio.h:extern int vsprintf(char *buf, const char *fmt,
va_list args);./include/stdio.h:extern int sprintf(char * buf, const
char *fmt, ...);
./include/stdio.h:extern int printf(const char *fmt, ...);
I never explicitly #include m68k-palmos/include/stdio.h, so it looks
like the compiler is doing it for me. Since the function is in a lib
file, I can't really peek at the source code for it. Oh well.
Thanks again,
Stephen Tang
[EMAIL PROTECTED]
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
