Memry allocation

[irimiab]

Just today I have met a problem:
When I needed to allocate a large bunch of memory, I used the following code:

temp=(char*)MALLOC(pApp->dataBufferLength*sizeof(char));

I needed several instructions like this one, and dataBufferLength was over 5000. The problem appeared at the seventh or eigth instruction like the one above. The solution was to enlarge the memory of the device (I used the Windows heap). But I tested the code using

temp=(char*)MALLOC(pApp->dataBufferLength*sizeof(char*));

instead of the first instruction. Sizeof(char*) returns 4 and sizeof(char) returns (obviouselly) 1. But the code works ONLY with the second instruction. Why does this happen ? The memory allocated should grow four times. If it doesn't work with the first instruction, why does it work with the second one ? :confused:

The code looks like this:

temp=(char*)MALLOC(pApp->dataBufferLength*sizeof(char*));
STRCPY(temp,pApp->dataBuffer);
temp2=temp;

//here I have several instructions that alters the temp pointer (the string) -i'm doing a string parsing

data1=(char*)MALLOC(STRLEN(temp)*sizeof(char*));
STRCPY(data1, temp);
FREEIF(temp2);
temp=NULL;

Is this ok, or there's a problem in my logic ?
I tried with sizeof(char), but the problem with the memory emerges (at the seventh block like the one above it crashes - doesn allocate the memory, or it freezes)


Thank You !

[ruben]

Pointer size is 4 byte. If you are doing sting manipulation shouldn't you be doing sizeof(char). With sizeof(char*) you are allocating 4 times more memory than you need.

[irimiab]

Indeed, but it seemed that with more memory allocated it worked better. Perhaps the fault is to the instruction STRLEN(temp), which could freeze if the given string doesn't end with '\0'.

Thank you ! ;)

[ruben]

If you pass incorrect parameters to many of BREW CRT helper function system will freeze or crash. :(

ruben

[irimiab]

You are right ! But in my case the problem was the following:

data1=(char*)MALLOC(STRLEN(temp));
STRCPY(data1,temp);

STRLEN returns the length of the string WITHOUT the ending NULL. When trying STRCPY, there was no place for the ending NULL in temp. The correct syntax is:

data1=(char*)MALLOC(STRLEN(temp)+1);
STRCPY(data1,temp);

It worked with

data1=(char*)MALLOC(STRLEN(temp)*sizeof(char*));
STRCPY(data1,temp);

because there was enough space for string copy, but the waste of memory was awful (four times the necessary) !

Thank you for your help ! :)

[pobrien]

In your code

>>

data1=(char*)MALLOC(STRLEN(temp)+1);
STRCPY(data1,temp);

<<

once you allocate memory for data1, I would explicitly set either the first byte to a NULL, or use MEMSET to set each byte of data1 to NULL.

STRCPY assumes you are copying from a source string to a target string, so both data1 and temp need to be NULL-terminated.

Whether or not BREW zeroes out heap allocated memory, it is worthwhile writing some utility functions that handle the details of dynamic string allocation, initialization and freeing.

Patrick.

[irimiab]

That's an interesting subject... I didn't think of that, indeed, but it seems to me that it works ok even if there is no initialization (wheter with MEMSET or manually). Yet I will try to implement this initialization and see if there is any improvent.

Anyway, your advice is very valuable as it shares an important programming tip.
Thank you ! ;)

[pobrien]

>>

... but it seems to me that it works ok even if there is no initialization

<<

Just because the particular instance works doesn't mean that the process is correct.

From what I have read in the BREW docs, whenever I define a fixed length array of char in the main struct, for example:

char szTest[21];

then BREW will initialize these 21 bytes to NULL.

However, if I use a pointer instead, as in

char *pszTest;

which I later initialize with MALLOC(), then there is no such guarantee about the values of the N bytes allocated. It is very possible that the garbage in those bytes works for you, in the sense that a NULL byte is present in the first N bytes, but there is no guarantee, and this is true for systems other than BREW, when working with strings in the "C" language.

C++ does a lot to clean up the programmatic interface to character strings, but while working in "C" it is preferable to create some utility functions and not neglect the details that will sooner or later corrupt an application.

Patrick.

[irimiab]

You are right, indeed ! I will make the initialization, just to work clean ! :)

Thanx !