Whoa, you are totally right O_o
I did not know that.
Also, if you have more than 256 exits, there is something horribly, horribly wrong with your code or you need to spread it out to multiple executables.
Whoa, you are totally right O_o
I did not know that.
Also, if you have more than 256 exits, there is something horribly, horribly wrong with your code or you need to spread it out to multiple executables.
These void main topics became boring. What about a script which would filter out all topics containing void main anywhere in the text...
MS-DOS is the same, except the limitation was due to the fact program exit code was handled by using "terminate with return code", INT 21H with AH = 4CH and AL = to exit code, with only an 8 bit register (AL) to return the exit code. I don't recall CP/M having exit codes, programs terminated by jumping to zero.Originally Posted by jimblumberg
That would put an unfair limitation on legitimate uses of "void main()" (e.g. code for many embedded devices). Granted, a lot of these devices are moving towards a declaration of "int main()", but I still see no reason to blanket-ban a potential code construct simply because it's not right to use most of the time (as opposed to all of the time).
Technically, most embedded software is not written in C, but in a language that looks and behaves exactly like C. Embedded software relies on "undefined" behavior all the time. This is the boundary between the abstract and the concrete.
According to the standard, doing something undefined could cause literally anything to happen. On an actual and specific system, what will happen can often be predicted and relied on (and in fact you must, if you ever hope to get anything accomplished).
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}
You speak true, and I took that into consideration before posting. However, I was not commenting on whether embedded device compilers are or are not strictly compliant to the standard. I was speaking to the comment (facetious or otherwise) that particular flavors of C should be outright banned on the basis that those flavors share a common idiom with an oft-used mistake in standard C coding.
In the case of embedded software written in C, I believe that if the compiler documents it as such, then void as the return type of the main function conforms to the C standard since that is specified to be entirely implementation defined. In C++, I believe it is an all or nothing proposition: the compiler either provides for a startup function with a different name, or conforms to the requirements for the global main function as if it were not a freestanding environment, otherwise the behaviour is undefined with respect to the standard.
Look up a C++ Reference and learn How To Ask Questions The Smart Way
Simply because it's the standard.
