Why does execution start at main()?

[Beni]

I have been programming in C for about a year now. It sounds silly,
but I never took the time to question why a C(or C++ or Java) program
execution begins only at the main(). Is it a convention or is there
some deeper underlying reason?

 

[Richard Bos]

I have been programming in C for about a year now. It sounds silly,
but I never took the time to question why a C(or C++ or Java) program
execution begins only at the main().

So... where else would you have it start? At exit()?

Basically, you have to have _some_ convention on where a program starts
executing; picking a standardised startup function name is as good a
choice as any.

Richard

 

[Eric Sosman]

I have been programming in C for about a year now. It sounds silly,
but I never took the time to question why a C(or C++ or Java) program
execution begins only at the main(). Is it a convention or is there
some deeper underlying reason?

Execution starts at main() because of a typographical
error in the documentation for early versions of the language.
The error wasn't detected until many thousands of copies of
the documentation had been printed, bound, and shipped to
eager users, so it was easier to change the software than
to go chasing after all those erroneous copies.

Before this error was perpetuated, C programs began
execution at mean().

 

[Dan Pop]

I have been programming in C for about a year now. It sounds silly,
but I never took the time to question why a C(or C++ or Java) program
execution begins only at the main(). Is it a convention or is there
some deeper underlying reason?

It is a convention between the people who wrote the C startup module and
the people who write C programs. Try to omit the main() function from
a C program and see what happens at link time:

fangorn:~/tmp 108> cat test.c
void foo(){}
fangorn:~/tmp 109> gcc test.c
/usr/lib/crt1.o(.text+0x18): In function `_start':
: undefined reference to `main'

This shows that the module /usr/lib/crt1.o that was automatically linked
to your program was calling main(), but the linker couldn't find that
function. Of course, you can fool most linkers, as they are not
particularly smart:

fangorn:~/tmp 111> cat test.c
int main;
fangorn:~/tmp 112> gcc test.c
fangorn:~/tmp 113>

But running the resulting executable is left for the fool or the brave
(or the foolishly brave ;-)

Note that this convention is valid only for hosted implementations.
Freestanding implementations may use a different convention (there may be
no main function in the kernel of your OS, even if it was written in C).

Dan

 

[Malcolm]

I have been programming in C for about a year now. It sounds silly,
but I never took the time to question why a C(or C++ or Java)
program execution begins only at the main(). Is it a convention or is
there some deeper underlying reason?

The name "main" is obviously just a convention - "start" or "begin" could
have been chosen just as easily.

In C++ "main" is a hangover from C, it would have been more logical to
define a special object (called "app" or something similar) which is
initialised at program start and destroyed on termination.

Execution has to start from somewhere, and having a reserved function name
is as good a method as any. There is the quirk that it is not possible to
call a C program from another C program - you have to change the callee's
"main" to "xmain" or something similar.

 

[Wendy E. McCaughrin]

: >
: > I have been programming in C for about a year now. It sounds silly,
: > but I never took the time to question why a C(or C++ or Java)
: > program execution begins only at the main(). Is it a convention or is
: > there some deeper underlying reason?
: >
: The name "main" is obviously just a convention - "start" or "begin" could
: have been chosen just as easily.

: In C++ "main" is a hangover from C, it would have been more logical to
: define a special object (called "app" or something similar) which is
: initialised at program start and destroyed on termination.

: Execution has to start from somewhere, and having a reserved function name
: is as good a method as any. There is the quirk that it is not possible to
: call a C program from another C program - you have to change the callee's
: "main" to "xmain" or something similar.

No. Dan Pop gave the correct explanation. Execution does NOT start with
main(), but with the C runtime ("crt") code which sets up a runtime
environment for main(), e.g.,: initializing argc, argv and envp.

 

[Leor Zolman]

: >
: > I have been programming in C for about a year now. It sounds silly,
: > but I never took the time to question why a C(or C++ or Java)
: > program execution begins only at the main(). Is it a convention or is
: > there some deeper underlying reason?
: >
: The name "main" is obviously just a convention - "start" or "begin" could
: have been chosen just as easily.

: In C++ "main" is a hangover from C, it would have been more logical to
: define a special object (called "app" or something similar) which is
: initialised at program start and destroyed on termination.

: Execution has to start from somewhere, and having a reserved function name
: is as good a method as any. There is the quirk that it is not possible to
: call a C program from another C program - you have to change the callee's
: "main" to "xmain" or something similar.

No. Dan Pop gave the correct explanation. Execution does NOT start with
main(), but with the C runtime ("crt") code which sets up a runtime
environment for main(), e.g.,: initializing argc, argv and envp.

Well, for that matter, execution doesn't "start" with the crt, but
when you boot the computer. Give the guy a break ;-)
-leor

 

[Martin Dickopp]

: >
: > I have been programming in C for about a year now. It sounds silly,
: > but I never took the time to question why a C(or C++ or Java)
: > program execution begins only at the main(). Is it a convention or is
: > there some deeper underlying reason?
: >
: The name "main" is obviously just a convention - "start" or "begin" could
: have been chosen just as easily.

: In C++ "main" is a hangover from C, it would have been more logical to
: define a special object (called "app" or something similar) which is
: initialised at program start and destroyed on termination.

: Execution has to start from somewhere, and having a reserved function name
: is as good a method as any. There is the quirk that it is not possible to
: call a C program from another C program - you have to change the callee's
: "main" to "xmain" or something similar.

No. Dan Pop gave the correct explanation.

No, Dan Pop gave a concrete example how the program startup looks like
on a particular implementation.

Execution does NOT start with main(), but with the C runtime ("crt")
code which sets up a runtime environment for main(), e.g.,:
initializing argc, argv and envp.

No, there is no requirement in the C standard for something called "crt"
to exist even in hosted environments. 5.1.2.2.1#1 is clear that the
only thing that is required to happen at program startup is that `main'
is called.

Martin

 

[Keith Thompson]

No. Dan Pop gave the correct explanation. Execution does NOT start with
main(), but with the C runtime ("crt") code which sets up a runtime
environment for main(), e.g.,: initializing argc, argv and envp.

Execution of what? Execution of the user's program starts with main.
What happens before that is implementation-specific; there may or may
not be anything called a "C runtime".

 

[Mabden]

Execution of what? Execution of the user's program starts with main.
What happens before that is implementation-specific; there may or may
not be anything called a "C runtime".

Yet "something" has to pass argc and the argv[] array to main(). While not
specifically defined, it IS guaranteed by K&R. I don't know if there's a
standard that says whether quotes should be stripped from arguments (i.e.
echo arg1 "arg2 has spaces" arg3)...

 

[Dan Pop]

No, there is no requirement in the C standard for something called "crt"
to exist even in hosted environments. 5.1.2.2.1#1 is clear that the
only thing that is required to happen at program startup is that `main'
is called.

The name is unimportant, what really matters is that a C startup module
that actually calls the main() function must exist on hosted
implementations. At least on those providing meaningful suport for
main's arguments.

Dan

 

[Dan Pop]

Execution of what? Execution of the user's program starts with main.
What happens before that is implementation-specific; there may or may
not be anything called a "C runtime".

According to the C standard, there is. It's just that the standard
calls it "execution environment":

3.12
1 implementation
particular set of software, running in a particular translation
environment under particular control options, that performs
translation of programs for, and supports execution of functions
in, a particular execution environment

Dan

 

[Martin Dickopp]

The name is unimportant, what really matters is that a C startup module
that actually calls the main() function must exist on hosted
implementations. At least on those providing meaningful suport for
main's arguments.

I think you misunderstood me. Here's the context to which I replied:

Execution does NOT start with main(), but with the C runtime ("crt")
code which sets up a runtime environment for main(), e.g.,:
initializing argc, argv and envp.

My point is that execution of the C program starts with `main'.
Whatever setup work is required is not part of the C program. As far
as the standard is concerned, it's sufficient if the arguments to `main'
appear by pure magic.

Martin

 

[Dan Pop]

I think you misunderstood me. Here's the context to which I replied:



My point is that execution of the C program starts with `main'.
Whatever setup work is required is not part of the C program. As far
as the standard is concerned, it's sufficient if the arguments to `main'
appear by pure magic.

And you completely missed my point, which was explaining why a convention
is necessary WRT the name of the function with which the program execution
starts, even if there is nothing in the standard itself making such a
convention necessary.

The need for such a convention was not immediately obvious to me, at the
time, coming from a Fortran (program execution starts with whatever is
neiter a function nor a subroutine) and BASIC (program execution starts
with the first executable line of code) background.

Dan

 

[Leor Zolman]

Execution of what? Execution of the user's program starts with main.
What happens before that is implementation-specific; there may or may
not be anything called a "C runtime".

Yet "something" has to pass argc and the argv[] array to main(). While not
specifically defined, it IS guaranteed by K&R. I don't know if there's a
standard that says whether quotes should be stripped from arguments (i.e.
echo arg1 "arg2 has spaces" arg3)...

Couldn't that "something" be the OS directly? It doesn't seem to me that
there's anything that would preclude argc/argv being set up for a C (or
whatever) program directly by the shell/command-processor, with the
C-generated executable having an entry point directly at the start of
main(). Granted, there are all sorts of other I/O-related setup chores that
typically happen in the run-time package and would have to be relocated
(to, say, an internal function invoked automatically from an I/O function
the first time any such function is called). And the way argc/argv need to
be set up for a C program might/would not work for other languages...but
this is just for the sake of argument ;-)
-leor

 

[Dan Pop]

[...]
No. Dan Pop gave the correct explanation. Execution does NOT start with
main(), but with the C runtime ("crt") code which sets up a runtime
environment for main(), e.g.,: initializing argc, argv and envp.

Execution of what? Execution of the user's program starts with main.
What happens before that is implementation-specific; there may or may
not be anything called a "C runtime".

Yet "something" has to pass argc and the argv[] array to main(). While not
specifically defined, it IS guaranteed by K&R. I don't know if there's a
standard that says whether quotes should be stripped from arguments (i.e.
echo arg1 "arg2 has spaces" arg3)...

Couldn't that "something" be the OS directly? It doesn't seem to me that
there's anything that would preclude argc/argv being set up for a C (or
whatever) program directly by the shell/command-processor, with the
C-generated executable having an entry point directly at the start of
main().

This is a highly unrealistic approach. You don't want to include
information about the C implementation in other components of the system,
that couldn't and shouldn't care less. All you need is a well defined
interface for passing the command line information from the command line
processor to the called program, regardless of the language in which it
was originally written. It is the C startup module's job to obtain this
information and to pass it to main() according to the C standard's
conventions. This way, the command line processor need not care about
the language used to write the executable that is being started.

Granted, there are all sorts of other I/O-related setup chores that
typically happen in the run-time package and would have to be relocated
(to, say, an internal function invoked automatically from an I/O function
the first time any such function is called). And the way argc/argv need to
be set up for a C program might/would not work for other languages...but
this is just for the sake of argument ;-)

On the contrary, a well thought of argument *must* take such issues into
account. Note that even Unix, which is the ideal environment for such an
approach, uses the classical startup module solution instead!

Dan

 

[Nick Keighley]

Malcolm <[email protected]> wrote:

: The name "main" is obviously just a convention - "start" or "begin" could
: have been chosen just as easily.

: In C++ "main" is a hangover from C, it would have been more logical to
: define a special object (called "app" or something similar) which is
: initialised at program start and destroyed on termination.

: Execution has to start from somewhere, and having a reserved function name
: is as good a method as any. There is the quirk that it is not possible to
: call a C program from another C program - you have to change the callee's
: "main" to "xmain" or something similar.

No. Dan Pop gave the correct explanation. Execution does NOT start with
main(), but with the C runtime ("crt") code which sets up a runtime
environment for main(), e.g.,: initializing argc, argv and envp.

where does it say this in the standard?

 

[Dan Pop]

where does it say this in the standard?

5.1.2.2.1

The values of argc and argv must come from somewhere. This somewhere
is typically called the C runtime environment or C startup module.

Dan

 

[Beni]

Well.. Thnx guys. Now I know that main is just a convention, and the
choice of this name is as good as any other. So I conclude that it
must had been Ritchie & Co who made this choice, and we are having to
follow it, whether we like it or not.
No, I would definitely not want execution to begin at exit().
And that piece about mean() was cool. It was almost believable
And call me stupid, but I need to do a google on "hosted" and
"freestanding" implementations.
Cheers!

 

[Leor Zolman]

On 12 May 2004 14:09:48 GMT, (e-mail address removed) (Dan Pop) wrote:
write the executable that is being started.

On the contrary, a well thought of argument *must* take such issues into
account. Note that even Unix, which is the ideal environment for such an
approach, uses the classical startup module solution instead!

From the perspective of what the Standard stipulates, though, an
environment such as the one I described looks like it would be compliant. I
never said this was a /practical/ choice for general-purpose modern
systems! But it does not seem so far-fetched to imagine a specialized
platform where all non-scripted apps are coded in C or C++ and such a
scheme could actually work if someone really wanted it to. Emphasis on the
"if".
-leor