This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

How to erase memory fields allocated by calloc?

Hi,
I am using calloc in a function to allocate memory to my array. This function writes to the array different number of elements each time the function is called. Here is my problem. Say for the first time function writes to all the 3 locations and next time it writes to only first 2 locations. After the second call, the 3rd memory locations still contains the value written by the first function call. I understand that is the way it works.But I want to know if there is a way to erase all the locations before calling the function again? Is there any built-in function available? Also when I print the values of array initially it doesn't print zeroes. I have read that calloc initializes the memory fields to 0's. Following is the function code.

function write_to_array(int value)
{
 int xdata *ascii_value,i;
 ascii_value = calloc(3, sizeof (int));
 for(i=0;value!=0;i++)
  {
    mod = value%10;
    c = mod+'0';
    ascii_value[i] = toascii(c);
    value/=10;
  }
 }

Parents
  • since 1987? I have not written even a single line for a PC, only for 'small embedded'. For that very reason, I have had no reason to look at the C standard since then.

    This is exactly the sort of attitude that has resulted in the world being full of unmaintainable, non-portable code.

    The 'C' standard applies to the 'C' language, not the platform.

Reply
  • since 1987? I have not written even a single line for a PC, only for 'small embedded'. For that very reason, I have had no reason to look at the C standard since then.

    This is exactly the sort of attitude that has resulted in the world being full of unmaintainable, non-portable code.

    The 'C' standard applies to the 'C' language, not the platform.

Children
  • I posted "A conforming freestanding implementation" still allow function pointers which, as i stated are "wrestled into an unsuited architecture"

    Since you can not 'attack' that statement, instead you attack my 'attitude'

    This is exactly the sort of attitude that has resulted in the world being full of unmaintainable, non-portable code.

    'portability' is arguable, but DO NOT accuse me of unmainatainable code, you have no foundation for that. Having the C standard in one hand while typing with the other is NOT a requirement for mainatainable code, au contraire, the least maintainable code I have seen has been written by people discussing whether code is "Real C".

    Portable code for a uC you have got to be kidding.
    That is one of those absolute fallacies that keep coming up.

    I guarantee you that my code is far more maintainable than much code I have seen that was littered with 'portability switches'. I can quote a statement I have made several times: "I do not give a hoot if code works, I care if it is maintainable". You can fix maintainable code that does not work, but get a bug report on unmaintanable code that 'works' and you are in deep Doo-Doo.

    Were I to replace a '51 with e.g. an ARM the code (even if written by Jack Sprat) would by no description imaginable be 'portable'. Is it possible to 'port' such code, sure, but that you just load it into the other compiler because C code is portable is pure and unadulterated BULLSHIT when talking about microcontrollers.

    There is so much going on in certain quarters to make a 'port' of something that 99.23% sure is never going to be 'ported' possible - what a wasted effort.

    Erik

    PS looking forward to seing what you can attack in this post :)

  • Were I to replace a '51 with e.g. an ARM the code (even if written by Jack Sprat) would by no description imaginable be 'portable'.

    Speak for yourself. I write portable code.