In general, I agree. In this particular case, it's an initialization routine called from a routine called from the event loop It's not going to be very deep on the stack, and it doesn't call anything else outside the OS.. Auto arrays don't fragment memory and they disappear cleanly.
The only problem I see is if the OS and/or interrupt handlers might load the stack further. "Jeff Loucks" <[EMAIL PROTECTED]> wrote: >You could probably auto a 2k buffer, but IMHO MemPtrNew() and MemPtrFree() >would be a better choice for an IO buffer. There are other users of your >limited stack. Yourself, if you call subroutines or use libraries, and >sometimes the OS and interrupts (but rarely on OS5). So, unless you enlarge >your stack, best to leave it alone and use heap. > >On 2/6/07, Walt Bilofsky <[EMAIL PROTECTED]> wrote: >> >> Thanks for your reply, Jeff. >> >> I mean an auto (stack) array. I want a large temporary buffer for a >> file copy operation. I guess I'll keep it at 2k. >> >> - Walt >> >> "Jeff Loucks" <[EMAIL PROTECTED]> wrote: >> >> >By local array, do you mean auto (on the stack), in your app data >> context, >> >or allocated from heap? >> > >> >Your stack is limited to the least of either 64K (without fiddling) or >> the >> >value specified in code resource #0, which defaults to about 4K. The >> stack >> >is best avoided for large data allocations, but can be enlarged for >> special >> >needs. >> > >> >Your app data context may be as large as 64K, but can't support a >> contiguous >> >chunk of more than 32K. However, your data context can hold a large array >> of >> >pointers to allocated chunks, with quite a large aggregate. >> > >> >You can allocate from the heap up to the size of the largest contiguous >> >chunk, which at times can be annoyingly small. If you need a reliably >> >expansive array, break it up into pieces that can be better accomodated >> with >> >a limited data context and within a fragmented heap. For example, instead >> of >> >trying to create a single contiguous array of 100 entries of a 1000 bytes >> >each, create an array of 100 pointers, each to a 1000 byte allocated >> entry. >> >A little less efficient (only in some ways), but much more flexible, and >> >nearly guaranteed to be accomodated. >> > >> >On 2/5/07, Walt Bilofsky <[EMAIL PROTECTED]> wrote: >> >> >> >> Thanks for your reply. >> >> >> >> The chart I remember had things like the stack and heap sizes for >> >> different OS versions. >> >> >> >> What I really need to know is, how large a local array can I >> >> reasonably declare in a C function and still have it work on most >> >> versions of Palm OS? >> >> >> >> - Walt >> >> >> >> "Dina Aronson" <[EMAIL PROTECTED]> wrote: >> >> >> >> >This might not be enough info, but this is from palm: >> >> > >> >> >http://store.palm.com/gridFamily/index.jsp >> >> > >> >> >Dina Aronson >> >> >[EMAIL PROTECTED] >> >> >-----Original Message----- >> >> >From: [EMAIL PROTECTED] >> >> >[mailto:[EMAIL PROTECTED] On Behalf Of Walt >> Bilofsky >> >> >Sent: Monday, February 05, 2007 2:39 PM >> >> >To: Palm Developer Forum >> >> >Subject: Palm Version Comparison >> >> > >> >> >Some years ago I knew where to find a web page listing memory >> >> >capacity, stack sizes, OS version, etc. for each of the Palm devices. >> >> >Can anyone point me to where that info would be now? >> >> > >> >> >Thanks for any assistance. >> >> > >> >> >- Walt Bilofsky >> >> >> >> -- >> >> For information on using the PalmSource Developer Forums, or to >> >> unsubscribe, please see http://www.palmos.com/dev/support/forums/ >> >> >> >> -- >> For information on using the PalmSource Developer Forums, or to >> unsubscribe, please see http://www.palmos.com/dev/support/forums/ >> -- For information on using the PalmSource Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
