main function

A

aarklon

Hi all,

I have heard many discussions among my colleagues that main is a user
defined function or not.

arguments in favour:-

1) if it is built in function it must be defined in some header file
but it is n't.

2) every time we are defining how the main function should work

arguments against:-

1)user defined functions cannot be called from command line

some say that it is a special user defined function ,which is the
starting point of execution of a C program.

now questions are

1) What exactly is the correct answer..????
2) in free standing implementations is main the starting point
of execution..????
 
I

Ian Collins

Hi all,

I have heard many discussions among my colleagues that main is a user
defined function or not.

arguments in favour:-

1) if it is built in function it must be defined in some header file
but it is n't.
Declared in a header, defined in a library.
2) every time we are defining how the main function should work

arguments against:-

1)user defined functions cannot be called from command line
Nor can any other, including main.
some say that it is a special user defined function ,which is the
starting point of execution of a C program.

now questions are

1) What exactly is the correct answer..????

The standard specifies main as the name of the function called at
program startup. There isn't a prototype in any headers because the
function can have one of two.

2) in free standing implementations is main the starting point
of execution..????

In a freestanding environment, the he name of the function called at
program startup is implementation defined.
 
M

Mark Bluemel

Hi all,

I have heard many discussions among my colleagues that main is a user
defined function or not.

What does the language specification say?

I suggest you get a copy of the standard (or the draft standard which is
available free) - see the FAQ for some pointers.

A lot of the questions you seem to be asking would be answered simply
by reading the standard rather than swapping opinions. In this case,
section 5.1.2 seems relevant (I'm using the C99 draft PDF).
arguments in favour:-

1) if it is built in function it must be defined in some header file
but it is n't.

There isn't, as far as I'm aware, any definition of "built in function"
in the C language specification. There are functions which an
implementation is required to provide and "main" isn't one of them.
2) every time we are defining how the main function should work

True enough. Though the standard defines what its arguments must be.
arguments against:-
1)user defined functions cannot be called from command line

some say that it is a special user defined function ,which is the
starting point of execution of a C program.

now questions are

1) What exactly is the correct answer..????

What does the standard say?
2) in free standing implementations is main the starting point
of execution..????

That depends on the implementation. The standard only mandates main for
hosted implementations.
 
S

santosh

Hi all,

I have heard many discussions among my colleagues that main is a user
defined function or not.

arguments in favour:-

1) if it is built in function it must be defined in some header file
but it is n't.

2) every time we are defining how the main function should work

arguments against:-

1)user defined functions cannot be called from command line

Neither is main() called from the command line. What you actually do is
invoke the _program_ from the command line. The implementation is
responsible for collecting any arguments and placing them at main()'s
disposal and calling main() itself.

Some implementations may have no means to specify command line
parameters and under some conditions it may not even be possible to
invoke the program at all, (example if it is the "only" program running
in the device).
some say that it is a special user defined function ,which is the
starting point of execution of a C program.

From the perspective of the program itself, yes. But usually it is not
the actual starting point.
now questions are

1) What exactly is the correct answer..????

It is user _defined_ but it _must_ be present to produce a executable
program. Also the Standard explicitly documents the portable forms for
main()'s signature. Implementations may allow other forms.
2) in free standing implementations is main the starting point
of execution..????

Not necessarily, though often a function called main() is still used for
the sake of convention.

Under hosted implementations, typically a short piece of "start-up code"
is responsible for calling main(). A freestanding program typically has
to itself implement this start-up code, as well as the code that
executes after a return from main(), if that is applicable.
 
M

Martin Ambuhl

Hi all,

I have heard many discussions among my colleagues that main is a user
defined function or not.

Why? Did you get tired of counting the dancing angels on the needle?
 
J

J. J. Farrell

Hi all,

I have heard many discussions among my colleagues that main is a user
defined function or not.

The answer to that obviously depends on exactly what you mean by "a user
defined function". C doesn't define the term, so its up to you and your
colleagues to define what you mean by it; once you've done that, you'll
know whether or not main is one.
 
J

jaysome

Hi all,

I have heard many discussions among my colleagues that main is a user
defined function or not.

More exactly, the definition of main is user-defined. Its prototype is
not declared by the implementation, and it follows that you--the
user--must not declare its prototype.

Your definition of main must conform to the C Standard, which
specifies the following acceptable choices:

int main(void) { /* ... */ }
int main(int argc, char *argv[]) { /* ... */ }

One of the most important things to notice about these definitions is
that main returns a type of int. Defining main to return any type
other than int is considered to be undefined behavior; some compilers
gladly accept a definition of main that defines a return type other
than int, such as void, but you should avoid using such a definition,
for the following reasons: 1) a return type other than int (e.g.,
void) is considered undefined behavior because it does not conform to
the C Standard, and 2) those same compilers will gladly accept a
return type of int, which does conform to the C Standard.

After you have defined your main function to return a type of int,
another important thing to keep in mind is that the actual value of
the return type can take on only a few specific values. These values
are 0, EXIT_SUCCESS and EXIT_FAILURE. Period. The latter two values
are macros defined in the Standard C header file <stdlib.h>. Returning
a value of 0 has the same effect as returning a value of EXIT_SUCCESS,
as far as the C Standard is concerned.

Whether or not you choose to return 0 or EXIT_SUCCESS from main is a
matter of preference and perhaps style. My preference is to return 0
if I never return an error status (i.e., EXIT_FAILURE) and return
EXIT_SUCCESS if I do return an error status. One benefit of this is
that for simple "Hello World!" programs, I can return 0 and do not
have to include <stdlib.h>. For example:

#include <stdio.h>
int main(void)
{
printf("Hello World!\n");
return 0;
}

If I return EXIT_FAILURE somewhere, someplace, then my (pseudo)code
might look something like this:

#include <stdlib.h>
int main(void)
{
if ( /* some expression */ )
{
/* error */
return EXIT_FAILURE;
}
else
{
/* success */
return EXIT_SUCCESS;
}
}

One final note about the function main. Sometimes its return type of
int simply does not make sense. Most if not all embedded software
written in C has a main function that looks something like this:

int main(void)
{
/* initialize stuff */
for ( ; ; )
{
/* do something */
}
return 0;
}

As long as the "do something" part does not contain a break statement
(which is hardly if never the case), the return statement will never
be executed. In that sense, and in the sense that there is no
environment to which to return a value on many if not most embedded
applications, it doesn't really make sense to define main to return a
type of int, does it? Some compilers and source code analyzers will
flag a warning about the return statement in the above example, saying
something to the extent that it is unreachable code. What really makes
the most sense in this instance is that the return type of main is
void, e.g.:

void main(void)
{
/* initialize stuff */
for ( ; ; )
{
/* do something */
}
}

If and when you ever run into such a situation, just make sure that
your compiler provides the option to define main with a return type of
void. Of course your code will be non-portable, but you should only be
using such compiler-specific options in an application domain such as
the embedded world, which is highly non-portable (though not totally
non-portable), especially for any non-trivial application.

Best regards
 
R

robertwessel2

More exactly, the definition of main is user-defined. Its prototype is
not declared by the implementation, and it follows that you--the
user--must not declare its prototype.


Why would there be a problem providing a prototype for main(), so long
as it matches one of the two acceptable forms, and matches the
eventual definition?
 
S

santosh

Why would there be a problem providing a prototype for main(), so long
as it matches one of the two acceptable forms, and matches the
eventual definition?

In fact if you use the "newer" style definition for writing main() you
automatically provide the prototype too. A separate prototype for
main() only rarely needed since main() is seldom called from other
functions.
 
K

Keith Thompson

jaysome said:
More exactly, the definition of main is user-defined. Its prototype is
not declared by the implementation,
Right.

and it follows that you--the
user--must not declare its prototype.

No, that doesn't follow at all. It's perfectly legal to declare a
separate prototype for main:

int main(void);

int main(void)
{
/* ... */
}

though that's useful only if you call main recursively. But even
without a separate prototype, the definition of main itself provides a
prototype.
Your definition of main must conform to the C Standard, which
specifies the following acceptable choices:

int main(void) { /* ... */ }
int main(int argc, char *argv[]) { /* ... */ }

One of the most important things to notice about these definitions is
that main returns a type of int. Defining main to return any type
other than int is considered to be undefined behavior; some compilers
gladly accept a definition of main that defines a return type other
than int, such as void, but you should avoid using such a definition,
for the following reasons: 1) a return type other than int (e.g.,
void) is considered undefined behavior because it does not conform to
the C Standard, and 2) those same compilers will gladly accept a
return type of int, which does conform to the C Standard.

That's not *quite* correct. A hosted implementation is allowed to
support other forms of main. For example, if a compiler supports and
documents "void main(void)", then a program that uses that form is
valid *for that implementation*, and does not invoke undefined
behavior. But your other reasons to avoid forms other than the two
guaranteed ones are valid.
After you have defined your main function to return a type of int,
another important thing to keep in mind is that the actual value of
the return type can take on only a few specific values. These values
are 0, EXIT_SUCCESS and EXIT_FAILURE. Period. The latter two values
are macros defined in the Standard C header file <stdlib.h>. Returning
a value of 0 has the same effect as returning a value of EXIT_SUCCESS,
as far as the C Standard is concerned.

Returning a value other than 0, EXIT_SUCCESS, or EXIT_FAILURE is
merely non-portable, not illegal.

[snip]
One final note about the function main. Sometimes its return type of
int simply does not make sense. Most if not all embedded software
written in C has a main function that looks something like this:

int main(void)
{
/* initialize stuff */
for ( ; ; )
{
/* do something */
}
return 0;
}

As long as the "do something" part does not contain a break statement
(which is hardly if never the case), the return statement will never
be executed. In that sense, and in the sense that there is no
environment to which to return a value on many if not most embedded
applications, it doesn't really make sense to define main to return a
type of int, does it? Some compilers and source code analyzers will
flag a warning about the return statement in the above example, saying
something to the extent that it is unreachable code. What really makes
the most sense in this instance is that the return type of main is
void, e.g.:

void main(void)
{
/* initialize stuff */
for ( ; ; )
{
/* do something */
}
}

If and when you ever run into such a situation, just make sure that
your compiler provides the option to define main with a return type of
void. Of course your code will be non-portable, but you should only be
using such compiler-specific options in an application domain such as
the embedded world, which is highly non-portable (though not totally
non-portable), especially for any non-trivial application.

Embedded systems typically have freestanding implementations. In a
freestanding implementation, the program's entry point is entirely
implementation-defined; it needn't even be called "main".

[...]
 
J

James Kuyper

Hi all,

I have heard many discussions among my colleagues that main is a user
defined function or not.

arguments in favour:-

1) if it is built in function it must be defined in some header file
but it is n't.

That argument doesn't hold up. Depending upon the implementation, there
might be quite a few functions that are not declared in standard
headers, but which are also not user defined. These might be hidden
helper functions that are called by routines from the C standard
library. These might be routines which are executed to emulate in
software C features for which native hardware support is lacking on a
particular platform, such as long-double _Complex arithmetic on a
platform which has native support only for 8-bit integer arithmetic.
2) every time we are defining how the main function should work

That is precisely the definition of "user defined", and the only
relevant argument you've cited.
arguments against:-

1)user defined functions cannot be called from command line

That's also true for main(). What you call from the command line is the
entire program, which eventually results in a call to main(); and later
on, it eventually may result in a call to any of the other user-defined
functions in the program.
 
P

pete

jaysome wrote:
More exactly, the definition of main is user-defined. Its prototype is
not declared by the implementation, and it follows that you--the
user--must not declare its prototype.

Because its prototype is not declared by the implementation,
it follows that you--the user--may declare its prototype.
 
G

Golden California Girls

jaysome said:
Hi all,

I have heard many discussions among my colleagues that main is a user
defined function or not.

More exactly, the definition of main is user-defined. Its prototype is
not declared by the implementation, and it follows that you--the
user--must not declare its prototype.

Your definition of main must conform to the C Standard, which
specifies the following acceptable choices:

int main(void) { /* ... */ }
int main(int argc, char *argv[]) { /* ... */ }

One of the most important things to notice about these definitions is
that main returns a type of int. Defining main to return any type
other than int is considered to be undefined behavior; some compilers
gladly accept a definition of main that defines a return type other
than int, such as void, but you should avoid using such a definition,
for the following reasons: 1) a return type other than int (e.g.,
void) is considered undefined behavior because it does not conform to
the C Standard, and 2) those same compilers will gladly accept a
return type of int, which does conform to the C Standard.

After you have defined your main function to return a type of int,
another important thing to keep in mind is that the actual value of
the return type can take on only a few specific values. These values
are 0, EXIT_SUCCESS and EXIT_FAILURE. Period. The latter two values
are macros defined in the Standard C header file <stdlib.h>. Returning
a value of 0 has the same effect as returning a value of EXIT_SUCCESS,
as far as the C Standard is concerned.

Whether or not you choose to return 0 or EXIT_SUCCESS from main is a
matter of preference and perhaps style. My preference is to return 0
if I never return an error status (i.e., EXIT_FAILURE) and return
EXIT_SUCCESS if I do return an error status. One benefit of this is
that for simple "Hello World!" programs, I can return 0 and do not
have to include <stdlib.h>. For example:

#include <stdio.h>
int main(void)
{
printf("Hello World!\n");
return 0;
}

If I return EXIT_FAILURE somewhere, someplace, then my (pseudo)code
might look something like this:

#include <stdlib.h>
int main(void)
{
if ( /* some expression */ )
{
/* error */
return EXIT_FAILURE;
}
else
{
/* success */
return EXIT_SUCCESS;
}
}

One final note about the function main. Sometimes its return type of
int simply does not make sense. Most if not all embedded software
written in C has a main function that looks something like this:

int main(void)
{
/* initialize stuff */
for ( ; ; )
{
/* do something */
}
return 0;
}

As long as the "do something" part does not contain a break statement
(which is hardly if never the case), the return statement will never
be executed. In that sense, and in the sense that there is no
environment to which to return a value on many if not most embedded
applications, it doesn't really make sense to define main to return a
type of int, does it? Some compilers and source code analyzers will
flag a warning about the return statement in the above example, saying
something to the extent that it is unreachable code. What really makes
the most sense in this instance is that the return type of main is
void, e.g.:

void main(void)
{
/* initialize stuff */
for ( ; ; )
{
/* do something */
}
}

If and when you ever run into such a situation, just make sure that
your compiler provides the option to define main with a return type of
void. Of course your code will be non-portable, but you should only be
using such compiler-specific options in an application domain such as
the embedded world, which is highly non-portable (though not totally
non-portable), especially for any non-trivial application.

Best regards

"Main" is "main" only in C. Other languages all have their own ways of letting
the linker and loader know were the system needs to jump (function call) to to
start execution. C could have used a switch to give the name of the function to
call to begin execution, with "main" being the default value, there is nothing
special about the name.

Now as to the two forms of "main" the loader likely passes the arguments even if
you ignore them, no harm in this as they pop off the stack upon return. Other
O/S may not even have a concept of argument values but the loader would still
have to pass a zero count and a null pointer on such systems as C requires it.
Or the complier might have to fake those depending on the implementation, but it
would be implementation dependent.

I'll leave it to the experts to say what might happen, besides the obvious
breaking of a script, if you don't return a value.
 
T

Thad Smith

Ian said:
(e-mail address removed) wrote:

It is programmer defined because the programmer writes the code for
main, which defines it.
In a freestanding environment, the he name of the function called at
program startup is implementation defined.

This is true. For freestanding implementations the entry routine is
normally main, with no parameters and no return value.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads


Members online

No members online now.

Forum statistics

Threads
473,766
Messages
2,569,569
Members
45,042
Latest member
icassiem

Latest Threads

Top