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; } }
I cant understand your problem. If the number of items in calloc call is fixed and it is only '3' then why cant you do it your self? some thing like:
ascii_value[0] = 0; ascii_value[1] = 0; ascii_value[2] = 0;
If the number of items in calloc call is fixed and it is only '3' then why cant you do it your self? Because calloc is supposed to return a memory block that is initialized with zeros. If it doesn't do that, something is wrong.
"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.
Erik
"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.
I noticed a comment or two about portablilty and embedded systems. I've been doing embedded systems for 20 years, both in assembly and C. I can assure you that Portability in an embedded system is both important and desirable, but very difficult to obtain.
As an example, I have had to port the same program now from a silabs F320 to a F310 to an F342 and now to an F040.
Each of these required slightly different code, most of which was abstracted by the use of headers for the machine specific portions. The code however, still has processor dependant sections. I wrote the code in such a way, that the processor dependent sections (such as initialization, powerup, powerdown, and port I/O are contained in single simple modules.
The code is however highly dependent on the Silabs 8051 architecture. It specifically is based around the PCA array. porting to another 8051 with a PCA array would be pretty easy. Porting to another processor would not be to hard (basically 5 short routines and one long one (the PCA handler) would have to be re-written, but 80% of the code will work untouched (with the use of some judicial defines).
So portablilty needs to be cast in terms of same architecture vs different architecture. Portablitly is necessary and desirable if you are doing the same general CPU/arch.
I have to weigh in on the side of Dynamic allocation has no place in embedded system (especially 8051's), along with Java and the rest of the abortions that people try to cram into embedded systems.
As for the arguement about char, unsigned char and signed char, from the compiler point of view they are all distinct types. From the functional point of view they are vastly different.
I do a lot of communication protocols. Some are 8 bit binary, some are not. You learn really quickly to explicitly use unsigned vs signed. Just as an example, suppose you have an 8 bit data stream. you define something like
unsigned int cksum=0; char c; c=input_from_port(); cksum+=C;
vs unsigned int cksum=0; unsigned char c; c=input_from_port(); cksum+=C; and I guarantee you that you will get the wrong checksum in one of these cases, because the compiler will treat C as a signed addition, rather than an unsigned one.
Chars are defined in an 8 bit world to be 8 bits, but subsequent expressions may sign extend characters that are not explicitly defined as unsigned char .
Some compilers treat signed char and char as signed number, while others treat unsigned char and char as unsigned numbers.
Cheers
As an example, I have had to port the same program now from a silabs F320 to a F310 to an F342 and now to an F040. ... The code is however highly dependent on the Silabs 8051 architecture. the 040 is standard '51 architecture the f3x is "Silabs architecture" aka the deviates.
So portablilty needs to be cast in terms of same architecture vs different architecture. Portablitly is necessary and desirable if you are doing the same general CPU/arch. portability is a joke. There are so many differences between the various uCs that while 'reuse of code' is valid, 'portability' is not. I have seen code that needed an enormous helping of tomato sauce just because it had been written 'portable'
I have migrated code from one '51 processor to another and if anyone told me that I 'ported' the code, I would call him a liar. Did i reuse a lot of code? of course, but ported - no way. If I had 'ported' I would have lost the advantages the processor I changed to had over its predecessor. I have seen 'ported' code that bit-banged IIC on processors with HW IIC, is that in any way reasomable - absolutely not. When asked, the so called programmer answered "If I use the HW IIC it is not portablr" baloney, that is putting a premium on something unlikely (porting to a 'dumber' uC).
As for the arguement about char, unsigned char and signed char, from the compiler point of view they are all distinct types. From the functional point of view they are vastly different. I vote for outlawing 'char', the only legal should be unsigned and signed, and that has the GLORIOUS side effect of making it impossible to use most of the library routines that all, because they were developed for 'full size' machines, really do not have a place in a '51.
<amateurish code bodging nonsense snipped>
I vote for outlawing 'char', the only legal should be unsigned and signed...
Look, you've already demonstrated your poor knowledge of standard 'C' and refused to try and educate yourself by reading the one document that might help - the 'C' standard - so please, would you try and refrain from posting rubbish on the topic you know so little about?
standard 'C' ... so please, would you try and refrain from posting rubbish on the topic you know so little about?
There is NOTHING in my post about "standard C" I do not know why you bring that up. Only about "C and its application in small embedded". If you are a proponent of the stupid "C is C wherever it is applied" I feel sorry for you.
I do not have ANY 'char' 'int' 'short' or so in ANY of my code everything is either signed or unsigned.
If you have a beef with that post "my coding style is different" not some blabber about 'standard C'.
You keep referring to me as an 'amateur', I have written C for small embedded 15+ years and heve developed a host of methods for EFFICIENT C for small embedded not STUIPID "standard C for small embedded"
Good lord man, ignoring The Standard's distinction between 'plain' char, "signed char", and "unsigned char", why do you even bother with C at all? Profound ignorance (intolerance, indifference, etc.) of the language/standard is no excuse! Just do it in assembly language if that's the case. No questions asked or answered -- simple, done, no discussion, "Kirk out".
View all questions in Keil forum