Originally Posted by
Salem
When you malloc for a string, do you remember to add 1
char *p = malloc( strlen(str) + 1 );
It's a common mistake in trying to implement "strdup"
Actually I usually malloc/realloc +2 bytes to cover possible string manipulation errors on my part. One extra byte is cheap insurance.
Originally Posted by
Salem
> For some reason it apparently does not always move newly (larger) realloc-ed memory to unused space.
There is no guarantee that the block will move when you increase the size (or decrease for that matter).
The only thing guaranteed is that the amount of memory preserved will be the smaller of the old and new sizes.
I understand that - my point was that it did not seem to be moving the block when there was not enough unused space. Sorry, I failed to mention there were page fault errors.
A realloc test app shows that realloc does seem to be working OK, but it also revealed a quirk (for lack of a better word) with this compiler that I was unaware of (or had forgotton). Normal string declarations must allow an extra char past the normal null. Here's an example with a 20 char string:
Code:
// This displays extra trash chars using "test_str[20]"
UCHAR test_str[20] = "xxxxxxxxxxxxxxxxxxxx"; // 20 x's
MessageBox(NULL, test_str, "Test", MB_OK|MB_TOPMOST);
// but displays fine using "test_str[21]"
UCHAR test_str[21] = "xxxxxxxxxxxxxxxxxxxx"; // 20 x's
MessageBox(NULL, test_str, "Test", MB_OK|MB_TOPMOST);
This is no doubt causing various problems because I assumed normal capacity.
Thanks, Mac