Effect of filling memory allocated by malloc()

cmalloc

Although I was able to correct my program and make it run properly, the reason why it wasn't working left me really curious.

I made a string with malloc and initialized it…then I did several strcat with it…and then I declares a file pointer…after that and if my string had more than approx. 26 chars the rest would be garbage…but if i declared the pointer previously to the string malloc it worked great. I just can't understand why, here it is some of the code if anyone thinks it's better to see more pls say so:

code:

char* holder=(char*)malloc(sizeof(char)*100);

for(i=0;i<100;i++)
    *(holder+i)='\0';

strcat(holder,"set xtics (");

//will ignore until the last n lines
for(i=0;i<26-n;i++)
    readline(sfd,line,29);

//will manage the last lines
char n_column[2];
char freq[3]={0};

for(i;i<26;i++)
{
    readline(sfd,line,29);
    sscanf(line+4,"%s",freq);
    write(out,freq,strlen(freq));
    write(out,"\n",1);
    strcat(holder,"'");
    sscanf(line,"%s",temp);
    strcat(holder,temp);        
    strcat(holder,"'");
    sprintf(n_column,"%d",counter); 
    strcat(holder," ");
    strcat(holder,n_column);
    //for the las one which won't have the ,
    if(i==25)
        strcat(holder,")");
    else
        strcat(holder,", ");
    counter++;      

}

//sending to gnuplot using pipe
printf("Before: %s\n",holder);
FILE *pipe = popen("gnuplot -persist","w"); //why can't it be here!!!!
printf("After: %s\n",holder);

output:

Before: set xtics ('a' 0, 'b' 1, 'c' 2, 'd' 3, 'e' 4, 'f' 5, 'g' 6, 'j' 7, 'k' 8, 'l' 9, 'm' 10, 'n' 11, 'o' 12, 'p' 13, 'q' 14, 'r' 15, 'u' 16, 'v' 17, 'w' 18, 'x' 19, 'y' 20, 'z' 21, 'h' 22, 'i' 23, 't' 24, 's' 25)

After: set xtics ('a' 0, 'b' 1, 'c' 2, 'd' 3, 'e' 4, 'f' 5, 'g' 6, 'j' 7, 'k' 8, 'l' 9, 'm' 10, 'n' 11, 'o'�

But if I change to:

FILE *pipe = popen("gnuplot -persist","w");

char* holder=(char*)malloc(sizeof(char)*100);
for(i=0;i<100;i++)
    *(holder+i)='\0';

Output is fine.

So why declaring the file pointer made such a difference? Or is something besides that?

Many thanks for you patience.

Best Answer

You have a 100 byte buffer and 208 byte string in it. The memory outside those 100 bytes does not belong to you.

Related Solutions

C++ – In what cases do I use malloc and/or new

Unless you are forced to use C, you should never use malloc. Always use new.

If you need a big chunk of data just do something like:

char *pBuffer = new char[1024];

Be careful though this is not correct:

//This is incorrect - may delete only one element, may corrupt the heap, or worse...
delete pBuffer;

Instead you should do this when deleting an array of data:

//This deletes all items in the array
delete[] pBuffer;

The new keyword is the C++ way of doing it, and it will ensure that your type will have its constructor called. The new keyword is also more type-safe whereas malloc is not type-safe at all.

The only way I could think that would be beneficial to use malloc would be if you needed to change the size of your buffer of data. The new keyword does not have an analogous way like realloc. The realloc function might be able to extend the size of a chunk of memory for you more efficiently.

It is worth mentioning that you cannot mix new/free and malloc/delete.

Note: Some answers in this question are invalid.

int* p_scalar = new int(5);  // Does not create 5 elements, but initializes to 5
int* p_array  = new int[5];  // Creates 5 elements

Do I cast the result of malloc

TL;DR

int *sieve = (int *) malloc(sizeof(int) * length);

has two problems. The cast and that you're using the type instead of variable as argument for sizeof. Instead, do like this:

int *sieve = malloc(sizeof *sieve * length);

Long version

No; you don't cast the result, since:

It is unnecessary, as void * is automatically and safely promoted to any other pointer type in this case.
It adds clutter to the code, casts are not very easy to read (especially if the pointer type is long).
It makes you repeat yourself, which is generally bad.
It can hide an error if you forgot to include <stdlib.h>. This can cause crashes (or, worse, not cause a crash until way later in some totally different part of the code). Consider what happens if pointers and integers are differently sized; then you're hiding a warning by casting and might lose bits of your returned address. Note: as of C99 implicit functions are gone from C, and this point is no longer relevant since there's no automatic assumption that undeclared functions return int.

As a clarification, note that I said "you don't cast", not "you don't need to cast". In my opinion, it's a failure to include the cast, even if you got it right. There are simply no benefits to doing it, but a bunch of potential risks, and including the cast indicates that you don't know about the risks.

Also note, as commentators point out, that the above talks about straight C, not C++. I very firmly believe in C and C++ as separate languages.

To add further, your code needlessly repeats the type information (int) which can cause errors. It's better to de-reference the pointer being used to store the return value, to "lock" the two together:

int *sieve = malloc(length * sizeof *sieve);

This also moves the length to the front for increased visibility, and drops the redundant parentheses with sizeof; they are only needed when the argument is a type name. Many people seem to not know (or ignore) this, which makes their code more verbose. Remember: sizeof is not a function! :)

While moving length to the front may increase visibility in some rare cases, one should also pay attention that in the general case, it should be better to write the expression as:

int *sieve = malloc(sizeof *sieve * length);

Since keeping the sizeof first, in this case, ensures multiplication is done with at least size_t math.

Compare: malloc(sizeof *sieve * length * width) vs. malloc(length * width * sizeof *sieve) the second may overflow the length * width when width and length are smaller types than size_t.