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; } }
"who said ANYTHING about "ignoring The Standard"
Nobody did. You left off the "'s distinction ...". Quoting the original complaint:
"... ignoring The Standard's distinction between 'plain' char, "signed char", and "unsigned char", ... "
The point (I think) is that there are three char types, all equally valid in small embedded C, but you have to understand the distinction between the three types and use them appropriately, regardless whether the target is "small embedded" or not.
"The fact is that plain 'char' is ambigouous and in small embedded C is not needed."
'Plain' char also has its place in "small embedded" systems.
Excerpts from The Standard's section 6.2.5 paragraphs 3-6 making the distinction between the three char types:
(3) "An object declared as type char is large enough to store any member of the basic execution character set. If a member of the basic execution character set is stored in a char object, its value is guaranteed to be nonnegative. If any other character is stored in a char object, the resulting value is implementation-defined but shall be within the range of values that can be represented in that type."
(4) "There are five standard signed integer types, designated as signed char, short int, int, long int, and long long int. ..."
(5) "An object declared as type signed char occupies the same amount of storage as a 'plain' char object. ..."
(6) "For each of the signed integer types, there is a corresponding (but different) unsigned integer type (designated with the keyword unsigned) that uses the same amount of storage (including sign information) and has the same alignment requirements. ..."
From those excerpts, we see that 'plain' char is intended for values from the basic execution character set, that those values are nonnegative, and storing any other value is implementation-defined (i.e., your implementation disambiguates it). So, simply put, for small embedded systems that deal with text-y things (e.g., an LCD message), 'plain' char is a perfectly valid, innocuous, and useful type.
From those excerpts, we also see that there are two char-sized integer types, "signed char" and "unsigned char", to be used when one wants to use an integer type other than the signed and unsigned varieties of short, int, long, and long long. These second and third char types, just like 'plain' char are useful and have their place in systems, "small embedded" or otherwise.
Don't use 'plain' char when you want do to signed integer arithmetic on char-sized objects; use signed char.
Don't use 'plain' char when you want do to unsigned integer arithmetic on char-sized objects; use unsigned char.
Do use 'plain' char when you are dealing with character set functionality.
Do use 'plain' char when you are dealing with character set functionality Please give me an example of "character set functionality" ONLY for a char in small embedded. Since small embedded rarely (never?) have a character e.g. ASCII on which no arithmetic is performed, using 'just' char there makes the ambiguity shine through.
Please give me an example of where you need to use 'just' char in a small embedded system. Please do not suggest to use the libraries which, since specified for 'full size', are way too 'comprehensive' and thus too large for small embedded.
DO NOTE, my suggestion 'outlaw char' was in relation to 'portability' (which I do not think apply to small embedded) but in reuse of code (which I do think apply to small embedded) the ambiguity may bite you.
Erik
"Please give me an example of "character set functionality" ONLY for a char in small embedded."
Is this really necessary? It's pretty basic stuff and I already did -- "... an LCD message ..." (i.e., a character string literal).
i asked: "Please give me an example of where you need to use 'just' char"
is "... an LCD message such an example - hardly.
"i asked: "Please give me an example of where you need to use 'just' char""
Yes, but there were two "Please give me...". I replied to the first one.
Anyway, why reject the LCD string literal example? Small systems can't have LCDs? How about a string literal going out a UART? Can small systems use a UART?
Anyway, why reject the LCD string literal example? Small systems can't have LCDs? How about a string literal going out a UART? Can small systems use a UART? I reject neither, what I post is that neither NEED 'plain' char. either will work with unsigned, signed and plain. This is an outcrop of the "you do not NEED 'plain' char in small embedded.
"... what I post is that neither NEED 'plain' char. either will work with unsigned, signed and plain."
No, string literals are comprised of 'plain' chars. You don't have any choice.
An excerpt from The Standard's section 6.4.5 paragraph 5:
"For character string literals, the array elements have type char ..."
If you use string literals, you need chars and you are using chars. They simply can't be avoided.