main() vs int main() vs int main(void) 
Author Message
 main() vs int main() vs int main(void)

I am curious what technical differences there are to declaring function
main as either:

main()

or

main(void)

or

int main(void)

In C, would one of these be more appropriate than the other?  If so, why?
I've looked at the K&R C book and another C book, both use just:

main()

And is it different in C++?

Thanks in advance!



Thu, 14 Oct 1999 03:00:00 GMT  
 main() vs int main() vs int main(void)


Quote:
>I am curious what technical differences there are to declaring function
>main as either:

>main()

>or

>main(void)

>or

>int main(void)

>In C, would one of these be more appropriate than the other?  If so, why?

They're essentially equivalent and the last two are truly equivalent, but
the last one is the most appropriate, because it protects you against a
not so uncommon mistake:

    struct bla {int i,j;}
    main(void){
    ...

Because of the missing semicolon on the previous line, main is now defined
as returning struct bla, which is not quite correct, but compilers are not
required to catch this mistake (and most don't).  If main is explicitly
defined as returning int, the compiler is required to catch the missing
semicolon and complain about it.

Things are a bit different with the first form, if your program explicitly
calls main, with the wrong number of arguments:

    main()
    {
        main(1);
    }

doesn't require a diagnostic, because of the old style definition of main,
but

    main(void)
    {
        main(1);
    }

does require a diagnostic.

So, while the three forms are equivalent for correct programs, the last
one requires the compiler to catch both kinds of programming errors,
therefore it is the preferred one.  Note that the other two forms are
likely to cause unwanted warnings if you put your compiler in "picky mode"
i.e. you select the highest warning level (e.g. gcc -Wall).

Quote:
>And is it different in C++?

No.

Dan
--
Dan Pop
CERN, IT Division

Mail:  CERN - PPE, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland



Fri, 15 Oct 1999 03:00:00 GMT  
 main() vs int main() vs int main(void)

Quote:


>>I am curious what technical differences there are to declaring function
>>main as either:

>>main()

>>or

>>main(void)
>Things are a bit different with the first form, if your program explicitly
>calls main, with the wrong number of arguments:

>    main()
>    {
>    main(1);
>    }

>doesn't require a diagnostic, because of the old style definition of main,
>but

>    main(void)
>    {
>    main(1);
>    }

>does require a diagnostic.

>So, while the three forms are equivalent for correct programs, the last
>one requires the compiler to catch both kinds of programming errors,
>therefore it is the preferred one.  Note that the other two forms are
>likely to cause unwanted warnings if you put your compiler in "picky mode"
>i.e. you select the highest warning level (e.g. gcc -Wall).

>>And is it different in C++?

>No.

Actually, C++ cleaned up the syntax so int f() is equivalent to
int f(void). So, int main() says main takes no arguments rather
than just being mum about what the arguments may be. int main()
and int main(void) mean the same thing in C++, but not in C.

(However, you can't call main in C++ so the point, as it relates
to main, may be moot.)

--
Craig

Manchester, NH
All evolution in thought and conduct must at first appear
as heresy and misconduct. -- George Bernard Shaw



Fri, 15 Oct 1999 03:00:00 GMT  
 main() vs int main() vs int main(void)

Quote:

>Things are a bit different with the first form, if your program explicitly
>calls main, with the wrong number of arguments:

>    main()
>    {
>    main(1);
>    }

>doesn't require a diagnostic, because of the old style definition of main,
>but

>    main(void)
>    {
>    main(1);
>    }

>does require a diagnostic.

Are you sure about that?
 I agree that

extern int f();

says nothing about the argument list.  However, a function definition
(as opposed to just a declaration), does show what arguments
the function takes.

I.e.
int f() {
   <function body>

Quote:
}

tells the compiler that this function takes no arguments. and so is
equivalent to

int f(void) {
     <function body>

- Show quoted text -

Quote:
}



Sun, 17 Oct 1999 03:00:00 GMT  
 main() vs int main() vs int main(void)



Quote:

>>Things are a bit different with the first form, if your program explicitly
>>calls main, with the wrong number of arguments:

>>    main()
>>    {
>>       main(1);
>>    }

>>doesn't require a diagnostic, because of the old style definition of main,
>>but

>>    main(void)
>>    {
>>       main(1);
>>    }

>>does require a diagnostic.

>Are you sure about that?

Yes.

Quote:
> I agree that

>extern int f();

>says nothing about the argument list.  However, a function definition
>(as opposed to just a declaration), does show what arguments
>the function takes.

>I.e.
>int f() {
>   <function body>
>}

>tells the compiler that this function takes no arguments.

Yes.

 and so is

Quote:
>equivalent to

>int f(void) {
>     <function body>
>}

No. The question here is when does the compiler have to generate a
diagnostic. There is a constraint in 6.3.2.2 that says:

"If the expression that denotes the called function has a type that
 includes a prototype, the number of arguments shall agree with the
 number of parameters. Each argument shall have a type such that its
 value may be assigned to an object with the unqualified versions of
 the type of its corresponding parameter."

There is no equivalent constraint for calls to non-prototyped functions;
argument mismatch there simply invokes undefined behaviour. A compiler
can diagnose this situation (as it can diagnose anything it likes) but
it doesn't have to. This is why prototypes are a much safer form of
function declaration (as well as causing appropriate type conversions).

--
-----------------------------------------


-----------------------------------------



Mon, 18 Oct 1999 03:00:00 GMT  
 main() vs int main() vs int main(void)

Quote:




> >>Things are a bit different with the first form, if your program explicitly
> >>calls main, with the wrong number of arguments:

> >>    main()
> >>    {
> >>       main(1);
> >>    }

> >>doesn't require a diagnostic, because of the old style definition of main,
> >>but

> >>    main(void)
> >>    {
> >>       main(1);
> >>    }

> >>does require a diagnostic.

> >Are you sure about that?

> Yes.

> > I agree that

> >extern int f();

> >says nothing about the argument list.  However, a function definition
> >(as opposed to just a declaration), does show what arguments
> >the function takes.

> >I.e.
> >int f() {
> >   <function body>
> >}

> >tells the compiler that this function takes no arguments.

> Yes.

>  and so is
> >equivalent to

> >int f(void) {
> >     <function body>
> >}

> No. The question here is when does the compiler have to generate a
> diagnostic. There is a constraint in 6.3.2.2 that says:

> "If the expression that denotes the called function has a type that
>  includes a prototype, the number of arguments shall agree with the
>  number of parameters. Each argument shall have a type such that its
>  value may be assigned to an object with the unqualified versions of
>  the type of its corresponding parameter."

> There is no equivalent constraint for calls to non-prototyped functions;
> argument mismatch there simply invokes undefined behaviour. A compiler
> can diagnose this situation (as it can diagnose anything it likes) but
> it doesn't have to. This is why prototypes are a much safer form of
> function declaration (as well as causing appropriate type conversions).

I'm sure Lawrence realizes this, but for others it is worth pointing
out that not only is it not necessary for the compiler to produce a
diagnostic if a function not declared with a prototype is called with
the wrong number of arguments, but the compiler must compile the
program in such a case, unless it can determine that the function is
actually called.

        void f()
        {
        }

        void g(int i)
        {
          if (i == 100)
            f(i);
        }

is legal unless g is actually called with an argument of 100.  The
compiler may issue a diagnostic for this, but that doesn't mean much
since it may issue a diagnostic for anything.  From ISO 6.3.2.2:

        ... the number and types of arguments are not compared with
        those of the parameters in a function definition that does
        not include a prototype declarator.

Michael M Rubenstein



Mon, 18 Oct 1999 03:00:00 GMT  
 
 [ 6 post ] 

 Relevant Pages 

1. int main() vs int main(void)

2. int main vs. void main

3. newbie question....int main, void main, main

4. what's the difference between void main(void) and int main(void)

5. void main(void) or int main() ??

6. main(void) vs void main ()

7. void main() or int main()?

8. void main or int main?

9. int main() OR void main()...

10. void main() <-> int main()

11. void main() or int main()?

12. int main() or void main()

 

 
Powered by phpBB® Forum Software