This is a multiple choice message.
.... a stupid programmer?
S/h/i/t thinks that void() main is the real truth because on his
computer is nothing than his own crap and main() gets invoked
magically only, so nothing happens that s/h/i/t has not in s/h/i/ts
own hands.
... an intelligent programmer who looks outside his onw work?
He/she knows that there is at least one instance on his computer that
invokes applications like an application invokes functions. So he
knows of exactly 2 different ways(*) to write his entry point from the
OS:
1. int main(void)
This interface is fine defined by the standard and the OS. What does
it mean?
a) the application returns an int to its caller to tell it about its
success or fail.
b) the application doen't use a single argument, it will still ignore
any whenever the caller will give one or more.
But in any way it will inform itzs caller correctly about its success
or if it fails why.
2. int main(int argc, char *argv[])
This interface differs only in the way that the application is aware
of arguments the caller may have choosen. It will look at them, it
will check them and works with.
But as the developer knows about the backgrounds he/she prepares the
whole application in the defined manner as the application will always
tell about its success.
... an application
An application behaves like a function inside an application. It gets
called from somewhere and the caller awaits a result. The caller likes
to get 0 or EXEI_SUCCESS every tome the application had worked well
and something unequal to that to be a hint that something went wrong.
So whenever the application returns a random number because the stupid
programmer was really crazy something random can occure.
Each application has an entry point that gets invoked when after
loading it gets called the first time. This entry point is well hidden
from the C application developer, because there is many different work
to do to serve the developer with a functional environment. An
incomplete list:
- initialise all static and extern variables not already done in the
binary file
- preparing the standard streams stdin, stdout and stderr to be clean
to use
- cleaning up internal resources (like memory management, file
handler,
direct API ointerfaces, and much more)
- setting up the backdoors (like exit(), signal handlers...)
- call the initial fuction by
- getting the parameters given by the caller
- prparing them to be matching the given rules (argc, argv)
- starting the first developer defined subroutine, known as main
- collecting the result from main
- close all resources the developer may have left open
- write outstanding buffers into theyr streams
- close open files, including stdin, stderr, stdout
- freeing memory the developer has left alone
- convey the result from main to the OS to let it convey it to the
caller
- flag the OS: I've done anything, remove me from the task list,
giving up all rights to use the CPU.
... an OS?
The OS offers one or more APIs to allow an application to invoke other
applications. It defines in that interface(s) a method to get the
result from that application. This is exactly the value given on
return in main or the value given as parameter to exit() and a flag
that tells that the OS was failing to execute the application.
Whenever main() of the called application returns others than the well
defined return values (0, EXIT_SUCCESS, EXIT_FAILTURE or an
implementation defined one it may occure that the OS will tell the
caller that it was unable to success the called application - even as
it has done all well - except to return an int from main.
Conclusion:
Any time a crazy programmer fails to return an int in main s/h/e/it
opens the doors wide for in best case unspezified behavior. Same as if
he writes an function, spezifiing that it returns a pointer and let
this function return without a given value.
The only reason no prototype for main exist is that main can be
defined in different ways, without receiving parameters and with
receiving parameters - but it must return always int because interface
description in each OS requires this.
This requirement is at least much older than K$R C and its precursors.
I have enough trust in the poeple who program these compilers that if they
went out of their way to provide void main(void) compilation, they insured
it would not trash anything.
This defines you as crazy programmer who doesn't care that there are
environments aroud who crashes when main() dosen't return int, who
lets the caller of an application die when main comes back with a
random number.
Go on, try to write a framework that does nothing than to call other
applications and does different work when an application tells it was
successfully completed and the application comes back with an error.
Be sure, you will ever fail if crazy M$ has written that application,
because it fails always in the standard. But means that you can ignore
any standard (even in M$ OSes?). No, it means only you proves you only
as ignorant, who is not interested in quality, security and stability.
(*) In practice the implementation may or may not define one or more
different ways to define interfaces to main - but at least all defines
that main returns int, some of them may offer a third or forth
parameter, but as this is only implementation defined that doesn't
matter here, because we're speaking only about the standard here.
--
Tschau/Bye
Herbert Rosenau
http://www.pc-rosenau.de eComStation Reseller in Germany
eCS 1.1 GA englisch wird jetzt ausgeliefert
