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?
75  9799  be******@hotmail.com (Beni) wrote: 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
Beni wrote:
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().
-- Er*********@sun.com
In <e5**************************@posting.google.com > be******@hotmail.com (Beni) writes: 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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
"Beni" <be******@hotmail.com> wrote in message
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.
Malcolm <ma*****@55bank.freeserve.co.uk> wrote:
: "Beni" <be******@hotmail.com> wrote in message
: >
: > 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.
On Wed, 12 May 2004 03:36:01 +0000 (UTC), "Wendy E. McCaughrin"
<we******@bluestem.prairienet.org> wrote: Malcolm <ma*****@55bank.freeserve.co.uk> wrote:
: "Beni" <be******@hotmail.com> wrote in message
: >
: > 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
"Wendy E. McCaughrin" <we******@bluestem.prairienet.org> writes: Malcolm <ma*****@55bank.freeserve.co.uk> wrote:
: "Beni" <be******@hotmail.com> wrote in message
: >
: > 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
--
,--. Martin Dickopp, Dresden, Germany ,= ,-_-. =.
/ ,- ) http://www.zero-based.org/ ((_/)o o(\_))
\ `-' `-'(. .)`-'
`-. Debian, a variant of the GNU operating system. \_/
"Wendy E. McCaughrin" <we******@bluestem.prairienet.org> writes:
[...] 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".
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org... "Wendy E. McCaughrin" <we******@bluestem.prairienet.org> writes:
[...] 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)...
--
Mabden
In <cu*************@zero-based.org> Martin Dickopp <ex****************@zero-based.org> writes: 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
DESY Zeuthen, RZ group
Email: Da*****@ifh.de Da*****@cern.ch (Dan Pop) writes: In <cu*************@zero-based.org> Martin Dickopp <ex****************@zero-based.org> writes:
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.
I think you misunderstood me. Here's the context to which I replied:
Wendy E. McCaughrin <we******@bluestem.prairienet.org> writes: 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
--
,--. Martin Dickopp, Dresden, Germany ,= ,-_-. =.
/ ,- ) http://www.zero-based.org/ ((_/)o o(\_))
\ `-' `-'(. .)`-'
`-. Debian, a variant of the GNU operating system. \_/
In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes: "Wendy E. McCaughrin" <we******@bluestem.prairienet.org> writes:
[...] 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".
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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
In <cu*************@zero-based.org> Martin Dickopp <ex****************@zero-based.org> writes: Da*****@cern.ch (Dan Pop) writes:
In <cu*************@zero-based.org> Martin Dickopp <ex****************@zero-based.org> writes:
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.
I think you misunderstood me. Here's the context to which I replied:
Wendy E. McCaughrin <we******@bluestem.prairienet.org> writes: 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. :)
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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
On Wed, 12 May 2004 10:32:08 GMT, "Mabden" <ma****@sbcglobal.net> wrote: "Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org... "Wendy E. McCaughrin" <we******@bluestem.prairienet.org> writes:
[...] > 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(). 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
--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: download BD Software's free STL Error Message Decryptor at: www.bdsoft.com/tools/stlfilt.html
"Wendy E. McCaughrin" <we******@bluestem.prairienet.org> wrote in message news:<c7**********@wildfire.prairienet.org>... Malcolm <ma*****@55bank.freeserve.co.uk> 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?
--
Nick Keighley
In <f1********************************@4ax.com> Leor Zolman <le**@bdsoft.com> writes: On Wed, 12 May 2004 10:32:08 GMT, "Mabden" <ma****@sbcglobal.net> wrote:
"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org... "Wendy E. McCaughrin" <we******@bluestem.prairienet.org> writes:
[...]
> 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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
In <8a*************************@posting.google.com> ni***********@marconi.com (Nick Keighley) writes: "Wendy E. McCaughrin" <we******@bluestem.prairienet.org> wrote in message news:<c7**********@wildfire.prairienet.org>... Malcolm <ma*****@55bank.freeserve.co.uk> 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?
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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
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!
On 12 May 2004 14:09:48 GMT, Da*****@cern.ch (Dan Pop) wrote:
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!
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
Dan
--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: download BD Software's free STL Error Message Decryptor at: www.bdsoft.com/tools/stlfilt.html
Dan Pop wrote: Martin Dickopp <ex****************@zero-based.org> writes:
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.
The only thing that forces such a "crt" module is the requirement
that main() be a re-entrant function. Without that initial code
in main could do all the system dependant initialization.
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
In <e5**************************@posting.google.com > be******@hotmail.com (Beni) writes: And call me stupid, but I need to do a google on "hosted" and
"freestanding" implementations.
No need to call you stupid: not every C programmer is supposed to be
familiar with the jargon of the C standard. But we're using it here,
because it's better than adopting our own jargon.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
In <53********************************@4ax.com> Leor Zolman <le**@bdsoft.com> writes: On 12 May 2004 14:09:48 GMT, Da*****@cern.ch (Dan Pop) wrote:
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!
From the perspective of what the Standard stipulates, though, an
environment such as the one I described looks like it would be compliant. I
True, and irrelevant. The convention was made with *real* implementations
in mind, by someone interested in creating a language for solving concrete
problems. The standard merely codified the existing practice, as it had
no other valid alternative.
When the answer to a question *necessarily* involves practical aspects
of real implementations, there is little point in speculating about
hypothetical implementations allowed by the standard.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
In <40***************@yahoo.com> CBFalconer <cb********@yahoo.com> writes: Dan Pop wrote: Martin Dickopp <ex****************@zero-based.org> writes:
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.
The only thing that forces such a "crt" module is the requirement
that main() be a re-entrant function. Without that initial code
in main could do all the system dependant initialization.
Reentrance is a non-issue, as main could use an internal static flag to
distinguish between its initial call and the others. But who's going to
make the initial call of main()? ;-)
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
On 12 May 2004 16:50:13 GMT, Da*****@cern.ch (Dan Pop) wrote:
From the perspective of what the Standard stipulates, though, an
environment such as the one I described looks like it would be compliant. I
True, and irrelevant.
Less so than discussions of programs without semicolons, though, no? ;-)
-leor
--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: download BD Software's free STL Error Message Decryptor at: www.bdsoft.com/tools/stlfilt.html
"Dan Pop" <Da*****@cern.ch> wrote in message
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.
This is worth pointing out. On hosted implementations there has to be some
code to set everything up and code to free memory and flush buffers on exit.
So the compiler seldom if ever compiles main as a normal function with the
entry point also happening to be the first instruction in the executable.
On Wed, 12 May 2004, Dan Pop wrote:
Leor Zolman <le**@bdsoft.com> writes:On Wed, 12 May 2004 10:32:08 GMT, "Mabden" <ma****@sbcglobal.net> wrote:
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.
This is, however, essentially the approach taken by *nix systems
as I see and understand them. The shell takes care of whether quotes should be stripped from arguments
; sets up argv (and implicitly argc), and passes those along to
a helper function supplied by the system which presumably sets up
argc and argv in an OS-standard location so that the C program can
access them. Now, it may be that in most *nix systems, argc and argv
are then fetched out of that standard location, possibly munged a
little, and then put somewhere different, by the "C runtime." But
there's no reason for an implementation to bother moving them around.
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.
Special case of the above: the command line processor could use the
same well-known and widespread standard as the C language. Then programs
written in C don't need any magic startup code.
On the contrary, a well thought of argument *must* take [I/O startup]
issues into account. Note that even Unix, which is the ideal
environment for such an approach, uses the classical startup module
solution instead!
One reason not to offload "startup" chores onto the shell is that
the shell itself has to start up at some point, too. Thus we would
need to make sure the kernel started up the shell using that same
startup code. But if the startup code was invoked simply with a
system call, anyway, I suppose there wouldn't be any maintenance
problem there.
-Arthur
"Mabden" <ma****@sbcglobal.net> writes: "Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org... "Wendy E. McCaughrin" <we******@bluestem.prairienet.org> writes:
[...] 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)...
Nothing in the C standard addresses the presence or absence of quotes
in command-line arguments (argv[]).
<OT>
In Unix, there's nothing special about quotation marks as far as
program invocation is concerned. They're used by the shell as part of
the syntax that specifies what arguments are going to be passed (so in
that sense they're "stripped"), but once that's determined the string
passed to as a program argument is just an arbitrary nul-terminated
string. I'm not as familiar with other systems, but I suspect many of
them are similar.
</OT>
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
Malcolm wrote: "Dan Pop" <Da*****@cern.ch> wrote in message
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.
This is worth pointing out. On hosted implementations there has
to be some code to set everything up and code to free memory and
flush buffers on exit. So the compiler seldom if ever compiles
main as a normal function with the entry point also happening to
be the first instruction in the executable.
Barring some wierd and wonderful use of statics, this cannot be
done in C because main must be callable recursively. The
following should run:
int main(int argc, char **argv)
{
if (argc) return main(--argc, argv);
return argc;
}
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
CBFalconer <cb********@yahoo.com> wrote: Malcolm wrote: So the compiler seldom if ever compiles
main as a normal function with the entry point also happening to
be the first instruction in the executable.
Barring some wierd and wonderful use of statics, this cannot be
done in C because main must be callable recursively. The
following should run:
int main(int argc, char **argv)
{
if (argc) return main(--argc, argv);
return argc;
}
This use of statics need hardly be weird and wonderful. In fact, it can
be as simple as this:
int __main_has_been_initialised=0;
int main(int argc, char **argv)
{
if (!__main_has_been_initialised) {
/* System-specific code to set up the program's data tables,
stack, and allocation arena, initialise the necessary statics
other than __main_has_been_initialised, initialise argc and
argv, and so forth. */
__main_has_been_initialised=1;
}
if (argc) return main(--argc, argv);
return argc;
}
All the rudiments of the startup code need to do now is initialise
__main_has_been_initialised, and call main(). Since the former can be
done by making it, and its initial value, part of the program image, all
that is left to do is call main() - making main() the startup code point
for that program!
Of course, this is not, AFAIAA, how most compilers and OSes actually
_do_ set up a program. But they _could_ do so, and it hardly qualifies
as "weird", IYAM.
Richard
On Wed, 12 May 2004 19:14:09 -0400 (EDT),
Arthur J. O'Dwyer <aj*@nospam.andrew.cmu.edu> wrote:
Special case of the above: the command line processor could use the
same well-known and widespread standard as the C language. Then programs
written in C don't need any magic startup code.
Save for the fact that things gets more complicated when you involve
intializing locales, aranging for atexit, loading the dynamic libraries,
aranging for cleanup code (someone mentioned flushing file buffers and
closing files) to be run after main returns, etc.
By the way, on unix like systems most programs realy starts in the code of
/lib/ld.so or something similar.
In its most simple form the startup code is similar to
exit( main(argc, argv) );
Setting up argc and argv in kernel code isn't difficult. All the other
things are realy best suited for a user level program, and instead of
compiling it into the main program by the compiler, linking to a standard
pice of code seems the better approach. The side effect is that the compiler
doesn't have to make main() a special case.
For the C programmer, the program starts in main() at that should be the
only thing that realy matters. What goes on before that, being that in
kernel code or some user level start up and clean up code shouldn't be
of any concert to the programmer.
Villy
In <8m********************************@4ax.com> Leor Zolman <le**@bdsoft.com> writes: On 12 May 2004 16:50:13 GMT, Da*****@cern.ch (Dan Pop) wrote:
From the perspective of what the Standard stipulates, though, an
environment such as the one I described looks like it would be compliant. I
True, and irrelevant.
Less so than discussions of programs without semicolons, though, no? ;-)
Pray tell, why are those programs irrelevant? They may not be
particularly interesting, once you've figured out how to code them, but
they are as relevant as you can get.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
In article <f1********************************@4ax.com>, Leor Zolman <le**@bdsoft.com> writes: On Wed, 12 May 2004 10:32:08 GMT, "Mabden" <ma****@sbcglobal.net> wrote:
"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org... "Wendy E. McCaughrin" <we******@bluestem.prairienet.org> writes:
[...]
> 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.
I haven't seen anyone point out yet that there is no "envp" argument
to main in C, in a conforming hosted implementation. In nonstandard
extensions to C, of course, there may all sorts of things.
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.
Not exactly. What's guaranteed by the standard is that in a hosted
implementation, program execution will begin in main, which will have
two arguments if it's defined as having two arguments. (It can also
be defined with no parameters.) The first argument will be an int
with a non-negative value; the second argument is a char ** with
certain guarantees about its value and the value of the char * objects
it points to.
Those guarantees are significant, but they are not strong enough to
require that all hosted implementations actually pass anything useful
to main.
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().
Whether a hosted implementation's execution environment is
conceptually divided into two entities called "OS" and "C runtime",
or divided up any other way, is purely a matter of definition as far
as C is concerned and completely irrelevant to the initial call to
main.
In my favorite oddball C implementation, EPM C for the AS/400, the
C execution environment is not "bound" to a C program at all; it
is part of a multilanguage execution environment that was loaded
by the OS on a job-by-job basis as needed. The first time an EPM
program is executed in an OS/400 job (which might be an interactive
session, or a batch job, or various other things), the EPM
environment is loaded and initialized. After that, any compiled C
program object can be invoked from anywhere in that job, until the
job ends or the EPM environment is explicitly terminated (by a system
call or user command).
--
Michael Wojcik mi************@microfocus.com
When most of what you do is a bit of a fraud, the word "profession"
starts to look like the Berlin Wall. -- Tawada Yoko (t. M. Mitsutani)
"Dan Pop" <Da*****@cern.ch> wrote in message
news:c7**********@sunnews.cern.ch... In <40***************@yahoo.com> CBFalconer <cb********@yahoo.com> writes:The only thing that forces such a "crt" module is the requirement
that main() be a re-entrant function. Without that initial code
in main could do all the system dependant initialization.
Reentrance is a non-issue, as main could use an internal static flag to
distinguish between its initial call and the others. But who's going to
make the initial call of main()? ;-)
The same magical fairy that calls _start() on your implementation.
Of course, since most OSes need to support binaries from arbirary languages,
picking a fixed name for program entry and using it for the C compiler's
runtime startup module is an obvious choice (though not the only one).
Runtime code for other languages would do something else if they have no
special meaning for the "main" label.
However, the short answer to the OP's question is "because the Standard says
so."
S
--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin
Beni wrote: 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?
Fortran compilers I knew many years ago generated an object
program called MAIN for program units without a FUNCTION or
SUBROUTINE statement. I don't know, though, that the language
excluded calling a SUBROUTINE or FUNCTION the name MAIN, but
I think it would fail.
PL/I allows one to give the main program any name desired,
and the system figures out how to start it.
Note that in Java applets the outer level user written method
is not called main, but for other programs it is main.
Just a convention that got incorporated into the language.
-- glen
In <9a******************************@news.teranews.co m> "Stephen Sprunk" <st*****@sprunk.org> writes: "Dan Pop" <Da*****@cern.ch> wrote in message
news:c7**********@sunnews.cern.ch... In <40***************@yahoo.com> CBFalconer <cb********@yahoo.com> writes: >The only thing that forces such a "crt" module is the requirement
>that main() be a re-entrant function. Without that initial code
>in main could do all the system dependant initialization.
Reentrance is a non-issue, as main could use an internal static flag to
distinguish between its initial call and the others. But who's going to
make the initial call of main()? ;-)
The same magical fairy that calls _start() on your implementation.
This fairy has no clue about the C standard and doesn't even want to
hear about it.
Of course, since most OSes need to support binaries from arbirary languages,
picking a fixed name for program entry and using it for the C compiler's
runtime startup module is an obvious choice (though not the only one).
Runtime code for other languages would do something else if they have no
special meaning for the "main" label.
That's the point: use a language neutral entry point and command line
passing convention and let the startup module of each language runtime
support handle the details. The functions performed by the startup module
belong to neither the OS nor the code generated by the compiler from the
application's sources. Neither of these entities wants to know anything
about the other.
However, the short answer to the OP's question is "because the Standard says
so."
There is no point in providing a stupid answer to a sensible question.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
In <xt0pc.8276$6f5.652934@attbi_s54> glen herrmannsfeldt <ga*@ugcs.caltech.edu> writes: Fortran compilers I knew many years ago generated an object
program called MAIN for program units without a FUNCTION or
SUBROUTINE statement. I don't know, though, that the language
excluded calling a SUBROUTINE or FUNCTION the name MAIN, but
I think it would fail.
Nope, if the compiler is careful. Because MAIN is not a reserved name,
the compiler must do whatever magic is needed to avoid conflicts:
fangorn:~/tmp 41> cat main.f
subroutine main
print *,'hello world'
end
call main
end
fangorn:~/tmp 42> f77 -c main.f
fangorn:~/tmp 43> nm main.o | grep -i main
00000000 T main_
0000003d T MAIN__
So, it appears that the name of the main program is actually MAIN_ and
the compiler mangles its symbols by appending an underscore (to avoid
clashes with the C library, because there is nothing preventing the
Fortran programmer from using names like puts and getc in his own code.
So, let's see what happens if I rename my main as main_:
fangorn:~/tmp 47> nm main.o | grep -i main
00000000 T main___
0000003d T MAIN__
The compiler detected the clash and appended two underscores to my main_
to keep both my code and its startup module happy. Needless to say, both
versions work as expected if properly linked:
fangorn:~/tmp 48> f77 main.f
fangorn:~/tmp 49> nm a.out | grep -i main
U __libc_start_main@@GLIBC_2.0
080486f0 T main
08048694 T main___
080486d1 T MAIN__
fangorn:~/tmp 50> ./a.out
hello world
This exercise also reveals the presence of a main in the executable
binary. A strong clue that the Fortran startup module is merely an
extension of the C startup module (the Fortran startup module begins
with a main function).
Of course, this analysis is valid only for the implementation used in
this experiment (g77 under Linux), but it shows that Glen's issue is
easily tractable.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Stephen Sprunk wrote:
[...] Reentrance is a non-issue, as main could use an internal static flag to
distinguish between its initial call and the others. But who's going to
make the initial call of main()? ;-)
The same magical fairy that calls _start() on your implementation.
Of course, since most OSes need to support binaries from arbirary languages,
picking a fixed name for program entry and using it for the C compiler's
runtime startup module is an obvious choice (though not the only one).
[...]
Strange... Every O/S I've used has no concept of "a fixed name for program
entry point", as executables don't even include symbol tables. (Except for
debugging purposes, it you so choose.)
--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody at spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
"Kenneth Brody" <ke******@spamcop.net> wrote in message
news:40***************@spamcop.net... Stephen Sprunk wrote: Of course, since most OSes need to support binaries from arbirary
languages, picking a fixed name for program entry and using it for the
C compiler's runtime startup module is an obvious choice (though not
the only one).
Strange... Every O/S I've used has no concept of "a fixed name for
program entry point", as executables don't even include symbol tables. (Except
for debugging purposes, it you so choose.)
Executables for the particular OS I checked (Linux) certainly have a symbol
table: nm shows a _start near the beginning of every binary I checked.
However, it just occured to me to strip a binary (not the default) and the
symbol table does indeed disappear completely. Apparently the _start symbol
isn't magical, so there must be something in the ELF (or whatever) object
format that dictates entry at _start in my implementation.
S
--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin
Kenneth Brody wrote:
(snip) Strange... Every O/S I've used has no concept of "a fixed name for program
entry point", as executables don't even include symbol tables. (Except for
debugging purposes, it you so choose.)
OS/360, and its successors, include external symbols in the
load module. The entry point is indicated, I believe in symbolic
form, in the end record of the load module. More complete symbol
tables can be included for debugging purposes.
Even more, a single load module can have multiple entry points,
similar to the multiple ENTRY points allowed in a Fortran subroutine.
-- glen
Dan Pop wrote: In <xt0pc.8276$6f5.652934@attbi_s54> glen herrmannsfeldt <ga*@ugcs.caltech.edu> writes:
Fortran compilers I knew many years ago generated an object
program called MAIN for program units without a FUNCTION or
SUBROUTINE statement. I don't know, though, that the language
excluded calling a SUBROUTINE or FUNCTION the name MAIN, but
I think it would fail.
Nope, if the compiler is careful. Because MAIN is not a reserved name,
the compiler must do whatever magic is needed to avoid conflicts:
(snip of one example)
This exercise also reveals the presence of a main in the executable
binary. A strong clue that the Fortran startup module is merely an
extension of the C startup module (the Fortran startup module begins
with a main function).
Of course, this analysis is valid only for the implementation used in
this experiment (g77 under Linux), but it shows that Glen's issue is
easily tractable.
I believe that in the OS/360 case, and I believe that VS/Fortran
still follows this, the name of the main program is changed
with the NAME= compiler option. A main program without that
option would be unable to call subroutines or functions named MAIN.
I never had the desire to name a subroutine main.
-- glen
And somewhere around the time of 05/14/2004 00:23, the world stopped and
listened as Stephen Sprunk contributed the following to humanity: "Dan Pop" <Da*****@cern.ch> wrote in message
news:c7**********@sunnews.cern.ch...
In <40***************@yahoo.com> CBFalconer <cb********@yahoo.com> writes:
The only thing that forces such a "crt" module is the requirement
that main() be a re-entrant function. Without that initial code
in main could do all the system dependant initialization.
Reentrance is a non-issue, as main could use an internal static flag to
distinguish between its initial call and the others. But who's going to
make the initial call of main()? ;-)
The same magical fairy that calls _start() on your implementation.
Of course, since most OSes need to support binaries from arbirary languages,
picking a fixed name for program entry and using it for the C compiler's
runtime startup module is an obvious choice (though not the only one).
Runtime code for other languages would do something else if they have no
special meaning for the "main" label.
However, the short answer to the OP's question is "because the Standard says
so."
S
The main() function is used by the C/C++ compiler to designate the entry
point of the program to the linker in either a.out, object, or obj
format. From the Unix environment, the ELF header specifies the entry
point of the program. Even in DOS/Windows, there is a field in the EXE
header that's labeled entry point. Here's a segment of the man elf page
on my FreeBSD Unix system:
Elf32_Addr Unsigned program address
Elf32_Half Unsigned halfword field
Elf32_Off Unsigned file offset
Elf32_Sword Signed large integer
Elf32_Word Field or unsigned large integer
Elf32_Size Unsigned object size
typedef struct {
unsigned char e_ident[EI_NIDENT];
Elf32_Half e_type;
Elf32_Half e_machine;
Elf32_Word e_version;
Elf32_Addr e_entry; **** Entry Point
Elf32_Off e_phoff;
Elf32_Off e_shoff;
Elf32_Word e_flags;
Elf32_Half e_ehsize;
Elf32_Half e_phentsize;
Elf32_Half e_phnum;
Elf32_Half e_shentsize;
Elf32_Half e_shnum;
Elf32_Half e_shstrndx;
} Elf32_Ehdr;
e_entry - This member gives the virtual address to which the system
first transfers control, thus starting the process. If the file has no
associated entry point, this member holds zero.
For the C/C++ programming language, it is defined that main() designates
start of execution of the program, which is called by the operating
system. The program header, which is produced by the linker, and is
programming language independent, gives the operating system all the
info it needs to properly load and execute the program.
#include <stdio.h>
int main() <--- Entry Point
{
printf("Hello World\n");
return(0);
}
In Pascal (My forte, and off topic in this group), the outermost begin
statement denotes the entry point.
Program Hello(Input, Output);
Begin <--- Entry Point
Writeln("Hello World");
End.
HTH.
--
Daniel Rudy
Remove nospam, invalid, and 0123456789 to reply.
"Stephen Sprunk" <st*****@sprunk.org> wrote: "Kenneth Brody" <ke******@spamcop.net> wrote: Strange... Every O/S I've used has no concept of "a fixed name for
program entry point", as executables don't even include symbol tables.
(Except for debugging purposes, it you so choose.)
Executables for the particular OS I checked (Linux) certainly have a symbol
table: nm shows a _start near the beginning of every binary I checked.
However, it just occured to me to strip a binary (not the default) and the
symbol table does indeed disappear completely. Apparently the _start symbol
isn't magical, so there must be something in the ELF (or whatever) object
format that dictates entry at _start in my implementation.
One of the ELF header fields is the offset at which execution starts.
There's an interesting thread where a guy tried to make the smallest
possible ELF executable: http://www.muppetlabs.com/~breadbox/...ny/teensy.html
On Fri, 14 May 2004 18:40:36 +0000, glen herrmannsfeldt wrote: I never had the desire to name a subroutine main.
What if you were designing a program for an electrical engineering bunch
and needed to determine the input in mili-amps to a specific part of the
circuitry? Remember that FORTRAN is case-insensitive as per the specs.
;)
(My point, in case it isn't obvious: "That word doesn't (always) mean what
you think it means.")
--
yvoregnevna gjragl-guerr gjb-gubhfnaq guerr ng lnubb qbg pbz
To email me, rot13 and convert spelled-out numbers to numeric form.
"Makes hackers smile" makes hackers smile.
August Derleth wrote: On Fri, 14 May 2004 18:40:36 +0000, glen herrmannsfeldt wrote:
I never had the desire to name a subroutine main.
What if you were designing a program for an electrical engineering bunch
and needed to determine the input in mili-amps to a specific part of the
circuitry? Remember that FORTRAN is case-insensitive as per the specs.
That was supposed to be past tense.
For many years my favorite name for quick programs, or otherwise
needing a name, what some people call foo, is this. So I have
had this.for, this.c, and finally this.java. It turns out
that this is a reserved word in java, and a class can't be named
this.
There is another reason to rename main, though, and that is the
ability to put multiple programs into a library.
-- glen
"Mabden" <ma****@sbcglobal.net> writes:
|> "Keith Thompson" <ks***@mib.org> wrote in message
|> news:ln************@nuthaus.mib.org...
|> > "Wendy E. McCaughrin" <we******@bluestem.prairienet.org> writes:
|> > [...]
|> > > 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)...
The actual contents of argv[i] are system dependant. I've used systems
which simply separated on blanks, quotes or no, and an implementation
which always called with argc == 2 and argv[1] containing the command
line would be legal.
--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Da*****@cern.ch (Dan Pop) writes:
|> In <f1********************************@4ax.com> Leor Zolman
|> <le**@bdsoft.com> writes:
|> >On Wed, 12 May 2004 10:32:08 GMT, "Mabden" <ma****@sbcglobal.net> wrote:
|> >>"Keith Thompson" <ks***@mib.org> wrote in message
|> >>news:ln************@nuthaus.mib.org...
|> >>> "Wendy E. McCaughrin" <we******@bluestem.prairienet.org> writes:
|> >>> [...]
|> >>> > 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.
So unrealistic that it is actually used by some OS's. Like all Posix
compliant systems, or Linux, for example.
Of course, just parsing the command line isn't all that ctr0 has to do;
under Posix, for example, the OS only knows low level file descriptors,
and crt0 sets up the FILE* stdin, stdout and stderr. (Although as far
as the Posix standard is concerned, it doesn't have to be this way.)
|> 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.
Unix, at least, traditionally has an intimate relationship with C.
|> 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.
In practice, under Unix, it is the exec'ing process which sets up the
argc/argv for the invoked process. This leads to some interesting
questions: is it even possible to implement a hosted C under Unix, since
there is no way to ensure that argv[0] contains the program name (and in
fact, several common Unix programs count on the fact that it doesn't).
And of course, about all the standard requires is that argv[0] either
contain the program name, or be an empty string. Provided that argc is
greater than zero, of course -- it would be perfectly conforming for an
implementation to always start main with argc == 0. And even
reasonable, if the system had no concept of command line.
--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34 Da*****@cern.ch (Dan Pop) writes:
|> >> 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?
|> 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.
Or the OS, or the invoking process, or ...
--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
glen herrmannsfeldt wrote: August Derleth wrote:
On Fri, 14 May 2004 18:40:36 +0000, glen herrmannsfeldt wrote:
I never had the desire to name a subroutine main.
What if you were designing a program for an electrical engineering bunch
and needed to determine the input in mili-amps to a specific part of the
circuitry? Remember that FORTRAN is case-insensitive as per the specs.
That was supposed to be past tense.
For many years my favorite name for quick programs, or otherwise
needing a name, what some people call foo, is this. So I have
had this.for, this.c, and finally this.java. It turns out
that this is a reserved word in java, and a class can't be named
this.
There is another reason to rename main, though, and that is the
ability to put multiple programs into a library.
It has never occurred to me to put complete programs in a library.
Why would you do that?
--
Joe Wright mailto:jo********@comcast.net
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
In article <72******************************@news.teranews.co m> "Stephen Sprunk" <st*****@sprunk.org> writes:
.... Executables for the particular OS I checked (Linux) certainly have a symbol
table: nm shows a _start near the beginning of every binary I checked.
However, it just occured to me to strip a binary (not the default) and the
symbol table does indeed disappear completely. Apparently the _start symbol
isn't magical, so there must be something in the ELF (or whatever) object
format that dictates entry at _start in my implementation.
No. Under Linux (and its Unix predecessors) execution starts at code
address 0 or somesuch. Indeed, a fixed address.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/ This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: subrat |
last post by:
Hello,
I know that the main( ) function is the starting point of execution in a C++
program.
What if an object is in the global space before main()?
Where is the constructor of the class object...
|
by: JohnQ |
last post by:
The way I understand the startup of a C++ program is:
A.) The stuff that happens before the entry point.
B.) The stuff that happens between the entry point and the calling of
main().
C.)...
|
by: itsraghz |
last post by:
Dear All,
I have an issue with destroy() method of java.lang.Process class. All what I am trying to do is, controlling the execution of one program through another. Let's say, Program B has to be...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
| | |
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and...
|
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated ...
|
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
| | |
by: bsmnconsultancy |
last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence...
| |
