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; } }
Thank you all for making it very clear when to go for dynamic allocation
If it is 'clear' then why state it as the above, why not state
NEVER use dynamic allocation on a '51.
Since there will be exceptions to every rule, I am sure that there is one case in 1.000.000 where it is correct to use it, but I have not heard of it. That there will be one case in much less than 1.000.000 where it is used, does not make it right
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.
Erik
I don't think you're in a position to comment on "ANSI compatibility" having never actually read the document in question.
If you'd like to give us all a laugh by inventing some examples to back up your statement please go ahead.
i posted "Keil need to be able to state "ANSI compatible" "
I don't think you're in a position to comment on "ANSI compatibility" having never actually read the document in question. The "document in question" is the Keil sales litterature, not the ANSI standard. And, contrary to your opinion, I have read that.
If you'd like to give us all a laugh by inventing some examples to back up your statement please go ahead. I'll gladly provide some fun, but examples of WHAT?.
However fun is one thing, derision is another and, it seems, you do not know the difference.
I'll gladly provide some fun, but examples of WHAT?.
Examples of 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".
Examples of features in Keil C51 that should not be there simply because they have to be "wrestled into the architecture" absolutely: dynamic allocation function pointers most often (have yet to find a 'no'): floating point
The usage of the above in a '51 sigularily indicate the users inability to select a suitable processor for the job.
the unique structure of the 51 with 3,4,5 or 6 types of memory (depending on how you count) in combination with the Harward architecture makes it an extremely suited controller for the applications it is designed for. However any attempt to use it as a general purpose processor will, at best be clumsy, and sometimes even impossible (who wants to wait 5 minutes on an answer to "what is the log of 1.349264?")
If using floating point on a '51 makes sense, then it would equally well make sense to use a Pentium for a toy. Either would represent a bad processor choice.
Examples of features in Keil C51 that should not be there simply because they have to be "wrestled into the architecture"
As usual you've snipped the quote to change the meaning so I'll repost what you actually said:
Here's your first example of something to satisfy the above statement:
absolutely: dynamic allocation
Guess what? You're wrong. I'll leave it to you to read that nice new copy of the standard you've bought to find out why.
<usual "'51 ain't no PC" rubbish snipped>
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. I have not "snipped the quote to change the meaning"
If you have a problem with english, let me try another way 1) There are features that The ANSI standard state a compliant C compiler must have. 2) To be able to state "ANSI C compatible", Keil need to include these feastures 3) Some such features are extremely combersome in the implementattion on the '51 architecture 4) Thus using such feature dramatically reduce the efficiency of the resulting code. 5) an example of such a feature would be dynamic allocation
now I have cut it in cardboard, and bent it in neon please elaborate on Guess what? You're wrong.
I'll leave it to you to read that nice new copy of the standard you've bought to find out why. I have no intention of purchasing a "nice new copy of the standard", till a problem should come up which what I have for a reference does not suffice. What I
I have no intention of purchasing a "nice new copy of the standard"
It's a pity, because if you did so (and read it, of course) you'd be able to avoid making false statements.
Dynamic allocation is not required to be implemented by a freestanding implementation.
ok 1) what is a 'freestanding implementation' ? 2) so I possibly missed one, what about function pointers which are a nightmare in the '51?
"1) what is a 'freestanding implementation' ?"
Aha - that's a term defined in the Standard...! ;-)
that's a term defined in the Standard will it cost me the price of the standard to find out or are you, Andy, going to tell me?
"will it cost me the price of the standard to find out ...?"
No. As posted elsewhere here, if you don't want to spend the small sum of $30 to buy from ANSI, you can get a working paper reflecting the current approved standard www.open-std.org/.../n1124.pdf from the working group's web page www.open-std.org/.../
i read the definition and am none the wiser.
I admit, I am limited in my C scope, 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.
"i read the definition and am none the wiser."
OK then, take a look at the C Rationale:
www.open-std.org/.../C99RationaleV5.10.pdf
Section 4, lines 9-13:
"By defining conforming implementations in terms of the programs they accept, the Standard 10 leaves open the door for a broad class of extensions as part of a conforming implementation. By defining both conforming hosted and conforming freestanding implementations, the Standard recognizes the use of C to write such programs as operating systems and ROM-based applications, as well as more conventional hosted applications."
Hopefully that sets the stage for The Standard's Section 4, paragraph 6:
"The two forms of conforming implementation are hosted and freestanding. A conforming hosted implementation shall accept any strictly conforming program. A conforming freestanding implementation shall accept any strictly conforming program that does not use complex types and in which the use of the features specified in the library clause (clause 7) is confined to the contents of the standard headers <float.h>, <iso646.h>, <limits.h>, <stdarg.h>, <stdbool.h>, <stddef.h>, and <stdint.h>. A conforming implementation may have extensions (including additional library functions), provided they do not alter the behavior of any strictly conforming program.)"
Hence Jack Sprat's comment about dynamic allocation not being required. Another example would be I/O as provided by the stdio.h interface (e.g., printf, putchar, etc.).
I read the very same and were none the wiser.
so, can it be expressed as "A conforming freestanding implementation excludes some standard C library funtions"
'so, can it be expressed as "A conforming freestanding implementation excludes some standard C library funtions"'
Yes, but specifically those facilities that would otherwise be provided by the list of headers not in the freestanding list: assert.h, complex.h, ctype.h, errno.h, fenv.h, inttypes.h, locale.h, math.h, setjmp.h, signal.h, stdio.h, stdlib.h, string.h, tgmath.h, time.h, wchar.h, and wctype.h.