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; } }
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"
Erik
"... 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.
you keep babbeling about my "lack of knowledge" about C, what makes you a judge of that
You persist in posting statements about 'C' that are incorrect. What other reason could there be to explain that than your lack of knowledge?
"Harping"? Now that's pretty offensive.
As usual.
I would prefer that folks take my posts as "educating".
There would appear to be no possibility of educating some people. Disagreement is probably the best you can hope for.
You . What other reason could there be to explain that than your lack of knowledge?
well then the fact that you "persist in posting statements about 'C' in small embdeed that makes it ineffective" show your immense lack of practical knowledge.
You just are so moribund in your 'adherence' that you can not possibly have any idea how to make a working product.
I do not give a hoot whether what I feed the C compiler is "real C" or whatever as long as what comes out is effective code. You however seem to be more concerned with what you feed the compiler than with what comes out.
well then the fact that you "persist in posting statements about 'C' in small embdeed that makes it ineffective"
Please provide a quotation to back up this statement.
My pleasure
I posted: "There are features in Keil C51 that should not be there simply because they have to be "wresteled into the architecture" but Keil need to be able to state "ANSI compatible" so they are there."
you replied: "If you'd like to give us all a laugh by inventing some examples to back up your statement please go ahead."
That reply from you do state "there are no C features wrestled in to fit the '51 architecture"
If you in any way state that e.g. malloc() has a place in effective C for the '51 my point is proven. naah, not even 'effective' leave it at C for the '51.
Why you think that:
"If you'd like to give us all a laugh by inventing some examples to back up your statement please go ahead."
has the same meaning as:
"there are no C features wrestled in to fit the '51 architecture"
is quite beyond me.
Amusingly, though, you've quoted your original statement:
"There are features in Keil C51 that should not be there simply because they have to be "wresteled into the architecture" but Keil need to be able to state "ANSI compatible" so they are there."
and then backed it up with your original incorrect example of malloc():
even though it has been patiently explained to you that a freestanding implementation is not required to implement malloc() in order to be ANSI compatible.
Do you ever listen to anything you are told, or do you just enjoy making a public fool of yourself?
I answered to: well then the fact that you "persist in posting statements about 'C' in small embdeed that makes it ineffective" Please provide a quotation to back up this statement. mentionong malloc() as an example
You reply: even though it has been patiently explained to you that a freestanding implementation is not required to implement malloc() in order to be ANSI compatible. WHAT ON EARTH does the fact that it is "not required" have to do with whether it "makes it ineffective".
If you could stay on the subject you, yourself bring up then, maybe, just maybe, we could discuss these issues.
Somehow, I, maybe erroneously, thought this forum was about Keil C and the toolset for the thread was C51
Before I waste my time answering this, would you please go back and read through the thread properly. If you still think the above makes any sense I will explain why it doesn't at that point.
WHAT ON EARTH does the fact that it is "not required" have to do with whether it "makes it ineffective".
Nothing. Who said it did?
The subject I, myself, brought up was your lack of 'C' knowledge, and I am staying very much on that subject.
in rsponse to my statement "malloc() is inefficient in the '51"
WHAT ON EARTH does my "'C' knowledge" have to with the fact that I have found that malloc() is ineficcient on the '51. You categorically dismiss C51 experience by refering to "the standard". What is most important a) the ability to write efficient code b) referring to "the standard" and nothing else
I'd say that a)would totally avoid malloc() and printf and b) would have them all over the place.()
The subject YOU 'inserted' (if you like that better than 'brought up') was that malloc() is not required by the standard.
1) we are discussing C51 (I hope) 2) C51 support malloc() 3) e.g. malloc() is ineffective 4) you reply 'not required by the standard'
SO, when I state "If you in any way state that e.g. malloc() has a place in effective C for the '51 my point is proven."
you do not respond, just dismiss by "It is not required by the standard"
WHAT ON EARTH does "not required by the standard" have to do with whether it is effective? Are you saying that if C51 can do something you want, but that is not "required by the standard" you should not use it
As stated before "I am concerned with what comes out as a result of what I put in. If what I put in is not to Jacks liking, but the result is the most effective, that is still the right thing to do"
Now, to take an even more 'radical' issue I ask "what place does printf() have in c for the '51?" I KNOW it is 'standard' I am NOT discussing that, PLEASE, should you answer, answer the question AS POSTED
I am of the opinion that many features in C51 "not required by the standard" are in response to those that have not realized that "the '51 ain't no PC"
No, it was in response to your statement that malloc() was required by the standard for a freestanding implementation.
WHAT ON EARTH does my "'C' knowledge" have to with the fact that I have found that malloc() is ineficcient on the '51.
I don't know. Who said it did?
Are you saying that if C51 can do something you want, but that is not "required by the standard" you should not use it
No.
You categorically dismiss C51 experience by refering to "the standard".
No, I don't. I point out errors in your knowledge of 'C'.
What is most important a) the ability to write efficient code b) referring to "the standard" and nothing else
That's about as much use as asking "Which is better - black or white"?
SO, when I state "If you in any way state that e.g. malloc() has a place in effective C for the '51 my point is proven." you do not respond, just dismiss by "It is not required by the standard"
I didn't make any statement to that effect so you're not really going to prove any points that way. I dismiss it because it is totally irrelevant to our discussion.
WHAT ON EARTH does "not required by the standard" have to do with whether it is effective?
Nothing. Why do you ask?
No. Are you?
Those who are unfortunate enough to work on your stuff after you will be able to answer that question, I'm sure.
Why don't you follow your own advice and stick to what we are discussing, instead of trying to divert the thread onto a topic you feel more comfortable with?
I do.
what we are discussing is what is most importanr in C51 "sticking to the standard" or "efficiency"
I vote for 1) maintainability (clarity of code and comments - which has NOTHING to do with "knowledge of the standard") 2)efficiency and 3) size.
That my knowledge of the "C standard" is not as complete as yours, is TOTALLY IRRELEVANT, what is relevant is "quality of code". If i achieve that by banning 'char' so friggin' what. If the code is clear and understandable, efficient and do not use excessive memory I am happy and so will "Those who are unfortunate enough to work on your stuff after you" be. If they want to add 'char' that is their prerogative, but the fact that I have used 'unsigned char' hardly makes "those" "unfortunate"
No. That is what you are trying to change the discussion to.
I vote for 1) maintainability (clarity of code and comments - which has NOTHING to do with "knowledge of the standard")
What do you think the purpose of standardisation is, then?
That my knowledge of the "C standard" is not as complete as yours, is TOTALLY IRRELEVANT
It is highly relevant to this discussion.
what is relevant is "quality of code".
You are giving the impression that you think that code conforming to the 'C' standard is of lower quality that non-conforming code. Do you wish to correct this impression or is that really the way you feel?
If i achieve that by banning 'char' so friggin' what.
You were given a most clear explanation of char, signed char and unsigned char by another contributor to this thread. Were you unable to understand it?