I want to know something regarding main function. For an application, the syntax for main function is something like: void main(void) { // ... // code // ... } but if we write as: int main(void) { // ... // code // ... return(0); } Here, who will handle the return value from main function. Normally embedded application is an infinite loop, so there wont be any chance of returning from main. But still it it terminates, then who will there to handle return value from main.
"Here, who will handle the return value from main function." Nobody will handle it - the RET will pop some nonsense return address off the stack and you program will run wild.
THIS AIN'T NO PC! in embedded (in case you missed it, the '51 and Keil make embedded projects) main does NOT return, why on earth would it? Erik
"Here, who will handle the return value from main function." Nothing will handle it - but that in itself is no problem. It is perfectly acceptable in 'C' for a function's return value to be ignored. "Normally embedded application is an infinite loop, so there wont be any chance of returning from main." Exectly - so it really makes no difference what return type you define for main() - since main() should never return! "But still it it terminates" No - that's the point: you need to ensure that main() never does terminate! (In fact, I think someone mentioned here a while back that C51 automatically adds an inifinite loop to catch any case where main() does exit...?)
Yes, C51 automatically starts over if you allow you program to fall out of main(). Behavior after exiting main is implementation-defined. It's good practice in embedded systems to write main as an infinite loop so that you do not rely on implementation-specific behavior. A return value for main() presumes some sort of entity which called main. Similarly, argc and argv imply some external entity that is parsing a command line, and which calls main. These parameters and return value are just a kludge left over from C's origin in Unix. Unix programs expect a return value, and Unix shells that invoke programs are all about command-line arguments. So, K&R found it a convenient hack to make their in-house programming language return a value to the OS and take arguments from it as well. However, this arrangement assumes Unix or at least a Unix-like operating system invoking your program. Most embedded systems don't have such, and the return value for main makes no sense. In my opinion, the proper signature for main is void main (void). Interface to a particular OS should be left to library calls. (Returning a value to Unix, for example, is as easy as calling exit(myReturnValue), rather than return myReturnValue. No need to clutter the language proper with extraneous environment-specific syntax. Similarly, you could have library calls to fetch command-line arguments.) But we're stuck with lots of legacy code that uses int main (argc, argv), and so the language definition will continue to support it.
These parameters and return value are just a kludge left over from C's origin in Unix Drew, while what you state is correct, I do not see the parametres for main() to be a kludge for non-embedded systems. A "run several things at the same time" computer (windows, linus, OS-X, Unix) may very well have the need for these things. Remeber, even DOS had return values. Erik