I'm working on an application that uses an editable text 'Field' to hold text that the user can edit. The user could indicate that this data is private (and should be encrypted).
My question is - while the user is editing the text in this field, the field (behind the scenes) may be resizing the memory buffer that holds the text - possibly copying it into a larger free block when it runs out of contiguous memory to support continued growth - or possibly releasing part of the block back to the heap after a large delete. Either way, the heap could end up storing fragments of the private data in unallocated memory...
Fields have a max chars property that the ui uses to stop input at a certain size. I'm not positive about this, but I'm pretty sure that the field's handle starts null and then is allocated to the full maxchars size + 1 when the first char is entered. Then it shouldn't need to be reallocated b/c the max chars property will limit the user input at the already allocated size. That's the beviour I've seen anyway.
From a purist's point of view - is there a good way to clean all this up before control passes to some other application? So far, I haven't thought of one, since I don't see a way for my application to put hooks into the interactions between the field control and the memory manager(!).
Now, if you want to kill that memory, you could zero it when you close the form. Something like this function (never been compiled)
void zero_field( FieldType *f )
{
FieldType *f = your_field();
MemHandle h = FldGetTextHandle( f );
FldSetTextHandle( f, 0 );
void *p = MemHandleLock( h );
MemSet( p, MemHandleSize( h ), 0 );
MemHandleFree( h );
}From a practical standpoint, I'm not sure how *real* the need is to develop an absolutely bulletproof solution - however, it's a puzzle,
and I wondered if any of the experts in this forum would have some
comments.
If you really want to be hard core about it, you can catch the keyDown events and check for focus on the field. Then you can handle the memory management yourself and be sure that important memory is not getting lost in the heap.
matt
-- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
