newbie question on understanding the main() function

If i write main like the following ways. Which one will compile and
why?

1. char * main();
2. char * main(int, char);
3. char * main(char);

I guess only first will(but, all three will flag a warning from the
compiler) because main in C needs argument names(not just argument
types) and cannot take a single argument(either zero or two
arguments). I tried this with GNU C compiler 4.3.2 on a Debian Linux
2.6.26.

I am a newbie so would appreciate any feedback if my understanding and
reasoning is correct.

Thanks

some wrote:
> If i write main like the following ways. Which one will compile and
> why?
>
> 1. char * main();
> 2. char * main(int, char);
> 3. char * main(char);
>
> I guess only first will(but, all three will flag a warning from the
> compiler) because main in C needs argument names(not just argument
> types) and cannot take a single argument(either zero or two
> arguments). I tried this with GNU C compiler 4.3.2 on a Debian Linux
> 2.6.26.

The first may compile, but on a hosted implementation such as yours main
returns int, not char*

--
Ian Collins

On 2010-02-08, some <s@mailinator.com> wrote:
> If i write main like the following ways. Which one will compile and
> why?

Possibly none.

> 1. char * main();
> 2. char * main(int, char);
> 3. char * main(char);

> I guess only first will(but, all three will flag a warning from the
> compiler) because main in C needs argument names(not just argument
> types) and cannot take a single argument(either zero or two
> arguments). I tried this with GNU C compiler 4.3.2 on a Debian Linux
> 2.6.26.

You don't need argument names in a declaration, only in a definition;
since it ends with a semicolon, this is just a declaration. On the
other hand, you've declared the second argument with the wrong type.

However, the compiler is free to flag this declaration as incorrect,
because it knows that main() returns int.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

some <s@mailinator.com> writes:
>If i write main like the following ways. Which one will compile and
>why?

This should be implementation-defined (»5.1.2.2.1 Program startup«:
»or in some other implementation-defined manner«). So, all these are
not maximally portable among conforming implementations. Every
implementation must accept

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

or

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

, so these are recommended.

some wrote:
> If i write main like the following ways. Which one will compile and
> why?
>
> 1. char * main();
> 2. char * main(int, char);
> 3. char * main(char);
>
> I guess only first will(but, all three will flag a warning from the
> compiler)

They are all wrong, but the compiler is not required to diagnose any of
them. This is one of those cases where the compiler is allowed to expect
you to know what you're doing; in such cases, if you /don't/ know what
you're doing, that's your problem, not the compiler's.

Note that the absence of argument names is not a problem because the
above are declarations, not definitions.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

On 2/7/2010 8:11 PM, some wrote:
> If i write main like the following ways. Which one will compile and
> why?
>
> 1. char * main();
> 2. char * main(int, char);
> 3. char * main(char);
>
> I guess only first will(but, all three will flag a warning from the
> compiler) because main in C needs argument names(not just argument
> types) and cannot take a single argument(either zero or two
> arguments). I tried this with GNU C compiler 4.3.2 on a Debian Linux
> 2.6.26.

All are likely to compile, because all are legal -- in a
free-standing program, where main() has no special significance.

In a hosted environment, though, all three are wrong. They
are likely to compile, but they are wrong nonetheless.

> I am a newbie so would appreciate any feedback if my understanding and
> reasoning is correct.

I can't tell about your understanding. Your reasoning, though,
is incorrect: "C needs argument names (not just argument types)" is
true for function definitions, but the three lines you've shown are
function declarations, *not* definitions. Right or wrong, all are
legal as declarations.

--
Eric Sosman
esosman@ieee-dot-org.invalid

Thanks to all who responded to my question.

Richard Heathfield wrote:
> some wrote:
> > If i write main like the following ways. Which one will compile and
> > why?
> >
> > 1. char * main();
> > 2. char * main(int, char);
> > 3. char * main(char);
> >
> > I guess only first will(but, all three will flag a warning from the
> > compiler)
>
> They are all wrong, but the compiler is not required to diagnose any of
> them. This is one of those cases where the compiler is allowed to expect
> you to know what you're doing;

How do I know which cases are such(where compiler will not flag an
error, but actually
legal so don't evoke an error message from compiler)? I realize cases
where I am
allocating/deallocating memory, doing pointer arithmetic, returning
address of a local
variable from a function are cases where compiler will not balk as
they are legal, but are
wrong?

Which book should I read to know about such cases?

Eric Sosman wrote:

> > If i write main like the following ways. Which one will compile and
> > why?
> >
> > 1. char * main();
> > 2. char * main(int, char);
> > 3. char * main(char);
> >
> > I guess only first will(but, all three will flag a warning from the
> > compiler) because main in C needs argument names(not just argument
> > types) and cannot take a single argument(either zero or two
> > arguments). I tried this with GNU C compiler 4.3.2 on a Debian Linux
> > 2.6.26.
>
> All are likely to compile, because all are legal -- in a
> free-standing program, where main() has no special significance.

How do I identify which code is legal(meaning compiler will not
produce any errors)? I thought all three were illegal, but was proved
wrong by the compiler.

> In a hosted environment, though, all three are wrong. They
> are likely to compile, but they are wrong nonetheless.
>
> > I am a newbie so would appreciate any feedback if my understanding and
> > reasoning is correct.
>
> I can't tell about your understanding. Your reasoning, though,
> is incorrect: "C needs argument names (not just argument types)" is
> true for function definitions, but the three lines you've shown are
> function declarations, *not* definitions. Right or wrong, all are
> legal as declarations.
>
> --
> Eric Sosman
> esosman@ieee-dot-org.invalid

Thanks for the clarification.

some wrote:
> Thanks to all who responded to my question.
>
> Richard Heathfield wrote:
>> some wrote:
>>> If i write main like the following ways. Which one will compile and
>>> why?
>>>
>>> 1. char * main();
>>> 2. char * main(int, char);
>>> 3. char * main(char);
>>>
>>> I guess only first will(but, all three will flag a warning from the
>>> compiler)
>> They are all wrong, but the compiler is not required to diagnose any of
>> them. This is one of those cases where the compiler is allowed to expect
>> you to know what you're doing;
>
> How do I know which cases are such(where compiler will not flag an
> error, but actually
> legal so don't evoke an error message from compiler)?

That's actually a very good question. Unfortunately, the only answer I
can come up with is "know the language". That isn't a very satisfactory
answer; it would be much more convenient if the compiler could catch all
our mistakes. Nevertheless, there are situations which the compiler is
not expected to be able to deal with. In "Standardese" (the language of
the C definition), such situations are described as "undefined".

It is worth getting hold of a copy of the Standard (free drafts are
available online), and spending a happy few hours searching the text for
"undefined". You may be surprised at just how many situations it covers.
For example, the behaviour of:

int i = INT_MAX;
++i;

is undefined. You'd think it would just wrap, wouldn't you? Well, it
might. Or it might not. And the compiler isn't obliged to catch
"overflow", as it's called. Why not? Well, let's imagine the user enters
a value at the keyboard, and your code adds 1 to it. Not an unreasonable
thing to want to do, is it? But if the user happens to enter the value
corresponding to INT_MAX, then you have overflow. The compiler can't
know that the user is going to enter that value. I suppose you could
have it flag every single addition, just in case - but that would
generate a vast number of false positives, which would waste far more
time than it saves.

So the answer really is "know the language". Know what's allowed, what
isn't, and what's on the edge. Avoid what isn't allowed, and try to keep
off the edge as much as you can.

This newsgroup excels at helping you to understand what's allowed and
what isn't, but there is no real substitute for getting and reading, and
re-re-re-re-re-re-re-re-re-reading, a copy of the Standard.

<snip>

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

some wrote:
<snip>

> How do I know which cases are such(where compiler will not flag an error, but actually legal so don't evoke an
> error message from compiler)? I realize cases where I am allocating/deallocating memory, doing pointer arithmetic,
> returning address of a local variable from a function are cases where compiler will not balk as they are legal, but
> are wrong?
>
> Which book should I read to know about such cases?

Since you claim to be a beginner, rather than trying to figure the
Standard, I'd recommend you to pick up a copy of The C Programming
Language 2nd Ed. by Kernighan & Ritchie. It's lucid, authoritative and
fairly comprehensive from the POV of the C90 standard. It's also
suitable as a "first book" to learn C from.

One other often recommended book would be C: A Reference Manual by
Harbison & Steele. It's meant to comprehensively cover the latest
version of Standard C, but it's not suitable for learning C from.

<http://cm.bell-labs.com/cm/cs/cbook/>
<http://www.careferencemanual.com/>

On 2010-02-08, santosh <santosh.k83@gmail.com> wrote:
><http://cm.bell-labs.com/cm/cs/cbook/>
><http://www.careferencemanual.com/>

Let me tack on my own recommendation:

http://knking.com/books/c/

This is my current favorite book on C. I actually think it's a better
teaching book than K&R.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

Richard Heathfield wrote:
> some wrote:
>> If i write main like the following ways. Which one will compile and
>> why?
>>
>> 1. char * main();
>> 2. char * main(int, char);
>> 3. char * main(char);
>>
>> I guess only first will(but, all three will flag a warning from the
>> compiler)
>
> They are all wrong, but the compiler is not required to diagnose any of
> them. This is one of those cases where the compiler is allowed to expect
> you to know what you're doing; in such cases, if you /don't/ know what
> you're doing, that's your problem, not the compiler's.
>
> Note that the absence of argument names is not a problem because the
> above are declarations, not definitions.
>


You're sure that the compiler isn't bothered by the lack of the ** in char?

I would think that these would traouble:

int main(int, char);
int main(char);

On 08/02/2010 03:46, some wrote:
> Thanks to all who responded to my question.
>
> Richard Heathfield wrote:
>> some wrote:
>>> If i write main like the following ways. Which one will compile and
>>> why?
>>>
>>> 1. char * main();
>>> 2. char * main(int, char);
>>> 3. char * main(char);
>>>
>>> I guess only first will(but, all three will flag a warning from the
>>> compiler)
>>
>> They are all wrong, but the compiler is not required to diagnose any of
>> them. This is one of those cases where the compiler is allowed to expect
>> you to know what you're doing;
>
> How do I know which cases are such(where compiler will not flag an
> error, but actually
> legal so don't evoke an error message from compiler)? I realize cases
> where I am
> allocating/deallocating memory, doing pointer arithmetic, returning
> address of a local
> variable from a function are cases where compiler will not balk as
> they are legal, but are
> wrong?
>
> Which book should I read to know about such cases?

A good starting place would be to read through the comp.lang.c FAQ at
http://c-faq.com/. There's a lot of discussion of different types of
not-well-defined-but-not-necessarily-error-producing code there to get
you started; particularly the sections on expressions, pointers and
memory allocation, but elsewhere too.

However, while it is a good resource, it is not enough on its own; it
must be read *in addition* to a good textbook such as those recommended
by santosh.

Also, if you haven't done so already, you should find out how to turn on
your compiler's stricter error checking modes. You mentioned you were
using gcc, so try:

gcc -ansi -pedantic -Wall -Wextra -o<destination> <source>

-ansi turns off extensions which are not allowed by the Standard
-pedantic emits all diagnostics (warnings) required by the Standard
-Wall turns on lots more warnings
-Wextra turns on even more warnings [can use -W instead of -Wextra]

In this case, -Wall enables the -Wmain warning:
-Wmain
Warn if the type of main is suspicious. main should be a function
with external linkage, returning int, taking either zero arguments,
two, or three arguments of appropriate types. This warning is
enabled by -Wall.

[If you're interested, the three-argument main() mentioned is a
nonstandard extension which (I think) provides a pointer to a data
structure representing the environment. Rather than using this
extension, you can just use the (standard, porable) getenv() function
instead.]

Phil

Phred Phungus wrote:

<snip>

> You're sure that the compiler isn't bothered by the lack of the ** in char?

The implementation is allowed, but not required, to be bothered.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

Philip Potter wrote:
> On 08/02/2010 03:46, some wrote:
[...]

> > How do I know which cases are such(where compiler will not flag an error, but actually legal so don't evoke
> > an error message from compiler)? I realize cases where I am allocating/deallocating memory, doing pointer
> > arithmetic, returning address of a local variable from a function are cases where compiler will not balk as they
> > are legal, but are wrong?
> >
> > Which book should I read to know about such cases?
>
> A good starting place would be to read through the comp.lang.c FAQ at
> http://c-faq.com/. There's a lot of discussion of different types of
> not-well-defined-but-not-necessarily-error-producing code there to get
> you started; particularly the sections on expressions, pointers and
> memory allocation, but elsewhere too.
>
> However, while it is a good resource, it is not enough on its own; it
> must be read *in addition* to a good textbook such as those recommended
> by santosh.
>
> Also, if you haven't done so already, you should find out how to turn on
> your compiler's stricter error checking modes. You mentioned you were
> using gcc, so try:
>
> gcc -ansi -pedantic -Wall -Wextra -o<destination> <source>
>
> -ansi turns off extensions which are not allowed by the Standard
> -pedantic emits all diagnostics (warnings) required by the Standard
> -Wall turns on lots more warnings
> -Wextra turns on even more warnings [can use -W instead of -Wextra]
>
> In this case, -Wall enables the -Wmain warning:
> -Wmain
> Warn if the type of main is suspicious. main should be a function
> with external linkage, returning int, taking either zero arguments,
> two, or three arguments of appropriate types. This warning is
> enabled by -Wall.
>
> [If you're interested, the three-argument main() mentioned is a
> nonstandard extension which (I think) provides a pointer to a data
> structure representing the environment. Rather than using this
> extension, you can just use the (standard, porable) getenv() function
> instead.]

I would also suggest turning on the switch[es] for optimisations
during compiling. The analysis the compiler does for optimisation
often points out many suspicious constructs like unusued/uninitialised
variables, dead code and so on, which might be of interest to those
learning to program. Look for the 'O' switch, or a variant, under most
compilers.