Why does this work?

[kevin arnold]

Hello everyone,
I chanced to hit upon a very weird piece of code snippet and i
cannot account for its
functioning. I tried gcc (even with -Wall option) and it worked fine.
So does CC (Solaris)
and aCC (HP-UX) without a warning. Now I can account for a, b, c - for
argc, argv and envp
but how to account for the other variables d and e? Are the compilers
at fault or I am missing
something? Thanks in advance for the help.
#include <stdio.h>
#include <stdlib.h>

int main (int a, int b, int c, int d, int e)
{
return (a + b + c + d +e);
}

Regards,

kevin.

 

[Tom]

The language only requires the compiler properly support
int main() and int main(int argc, char* argv[])
Other signatures (as long as they return int) are up to the
language to deal with. Most likely you are just violating
the definitions and these end up not being resolved at link time.

I think there is more going on here then you gave the OP credit for,
but I also think it may be compiler-specific.

Here's the OP's code, edited to eliminate the C-specific header file
#includes:

int main (int a, int b, int c, int d, int e)
{
return (a + b + c + d + e);
}

When I compile and link this as a C (not C++) with all diagnostics
turned on, gcc version 3.3 gives me the expected warnings:

C:\djgpp\mystuff>gcc -W -Wall -pedantic -o mainarg.exe mainarg.c

mainarg.c:3: warning: second argument of `main' should be `char **'
mainarg.c:3: warning: third argument of `main' should probably be
`char **'
mainarg.c:3: warning: `main' takes only zero or two arguments

(Despite what you said about the definitions not being resolved at
link time, gcc will successfully link the program and generate an
executable. The return value of the program upon execution is
presumably garbage.)

But if I compile and link the exact same program as a C++ program,
again with all diagnostics turned on, gcc version 3.3 generates no
diagnostic:

C:\djgpp\mystuff>gcc -W -Wall -pedantic -o mainarg.exe mainarg.cpp

In other words, the compiler is issuing a diagnostic if it's a C
program, but not if it's a C++ program. I would have expected the
compiler to generate the same diagnostic in both cases.

(FWIW, Comeau's online compiler compiled the program both as a C
program and as a C++ program without generating a diagnostic in either
case.)

I assume this is compiler-specific - i.e., a bug (or "feature") in
gcc, not a C++ language issue. But before I go complaining to the gcc
mailing list, can anyone think of a reason why, as a C program, this
should get a diagnostic, but not as a C++ program?

Best regards,

Tom

 

[Ron Natalie]

I assume this is compiler-specific - i.e., a bug (or "feature") in
gcc, not a C++ language issue. But before I go complaining to the gcc
mailing list, can anyone think of a reason why, as a C program, this
should get a diagnostic, but not as a C++ program?

Neither language requires a diagnostic.

 

[Tom]

Neither language requires a diagnostic.

Agreed. Perhaps I phrased my question carelessly by using the word
"should" instead of "would." Allow me to rephrase it. Does anyone
know of reason, either based on the language specification or common
usage, why a compiler writer would elect to have the compiler issue a
diagnostic in this situation for C code but not for C++ code?

(I recognize that a C++ compiler and a C compiler are separate, but I
hope everyone understands the question I'm asking here.)

Best regards,

Tom

 

[Ron Natalie]

I don't claim to know for certain, but here's a legitimate model of what
could be happening:

In C, there is only one function named main and it has a known prototype.
The compiler can warn you about it when you use the wrong number of
arguments.

In C++, there can be many functions named main. You defined one of them;
there's nothing for the compiler to complain about. The linker either found
a default main(int,char**)

Main is "special" in both langauges. There is no prototype in C for main.
The compiler is required to recquired to recognize both of the common
forms (void and with the arglist). The same is true of C++. Neither
language limits the implementation from accepting other forms of main.

 

[Michiel Salters]

[...]
In C++, there can be many functions named main.[...]

I wonder from where you get this nonsense. The Standard
clearly states in '3.6.1 Main function' subclause: "This
function shall not be overloaded."

Victor

Sure. Overloading is limited to namespaces, however. That means
myNameSpace::main( std::string ) doesn't overload the ::main( )
function.

3.6.1/3 is clear:
The function main shall not be used (3.2) within a program. The
linkage (3.5) of main is implementation-defined. A program that
declares main to be inline or static is ill-formed. The
name main is not otherwise reserved. [Example: member functions,
classes, and enumerations can be called main, as can entities
in other namespaces. ]

used(3.2) means you can't call ::main( ) recursively etc. That's
good, since it allows the compiler to hide the global ctor calls
in the compiled version of main().

Regards,