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; } }
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:
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.
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
Erik
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.
thanks Dan
now back to the original issue
"A conforming freestanding implementation" still allow function pointers which, as i stated are "wrestled into an unsuited architecture"
'"A conforming freestanding implementation" still allow function pointers which, as i stated are "wrestled into an unsuited architecture"'
Yes, in fact must allow in order to be conforming. How an implementation achieves that conformance (i.e., code production) for a language feature and whether or not that suits the target application's requirements for functionality versus performance is left as an exercise for the developer.
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.
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'
'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.
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.