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; } }
"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 gather that your philiosophy is 'purity' (whatever the cost)."
Pure efficiency with the lowest cost possible.
How can you maintain 'pure' C and go for efficiency?. No, i am not talking about going to assembler (which I do when needed) but things like 'taking advantage' of the library functions.
lowest cost possible is that development cost or unit cost?
Erik
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?
"How can you maintain 'pure' C and go for efficiency?."
They are not mutually exclusive.
"is that development cost or unit cost?
We try to minimize both, but optimizing one typically has the opposite effect on the other.
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.
They are not mutually exclusive. Oh, well, 'pure' may have been the wrong word, I am still, after 10+ years, remembering the "real C" idiot I fired.
"is that development cost or unit cost? We try to minimize both, but optimizing one typically has the opposite effect that seems to be the case in my world too. In a place where I once worked the formula was if [cost of optimizing development calculated at 5 times anticipated time] / ([unit savings] * [anticipated unit count]) came out in favor, then optimize.
"... 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.
"In a place where I once worked the formula was ..."
Or like when they want it "small" and "soon" and "cheap". They can pick only two.
agreed
what we are discussing is not 'C' but design philosophy
Not so. The discussion is most definitely about 'C', a subject on which you have much to say despite a fundamental lack of knowledge.
you keep babbeling about my "lack of knowledge" about C, what makes you a judge of that. That I apply C is a sensible way, instead of harping on what is C and what is not C does not indicate "lack of knowledge' but rather "intelligent application in an environment the language was not originally intended for"
"... instead of harping ..."
"Harping"? Now that's pretty offensive. I would prefer that folks take my posts as "educating".
sorry, Dan, addressed to Jack.
Dan, you and I may differ, but I have yet to see you post derogatives about me, whereas Jack seems to enjoy doing so.