Thread: Declare 'int main()', in C, isn't the same as in C++

I'm using that to illustrate why this is not a function prototype:

Code:

int f();

That it is an obsolescent feature is secondary to my point, and I note that you brought up the point that it is an obsolescent feature yourself in post #3, not me. (I merely used it so I didn't have to go digging around the standard for other examples.)

Ok, what we have until now: This declarator uses an obsolete syntax (but valid); You said this is not a prototype, it is (unless we discard obsolete, but possible, constructions)... I said we can do calls to functions with empty parameter list with any number and types of arguments. The standard advises against this pratice (I granted you this)... And the list of undefined behavior (Annex J) only says about functions without prototypes in scope...

Take a look at this advice @ 6.5.2.2 $2 and you'll see: "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...". Notice the use of "shall"... The entire specification is an adivice, too little is prohibited... I stated the fact, as far as I know, that every C compiler accepts this behavior without any warnings or errors.

If we agree that "shall" should be interpreted as "mandatory", then, every compiler I know is wrong (from the old Turbo-C 2.01 to the latest GCC, including old proprietary compilers for AIX, HP-UX, VMS - yep, I got my hands on them in the past!)...

Originally Posted by flp1969

You said this is not a prototype, it is (unless we discard obsolete, but possible, constructions).

It isn't. The standard says it isn't because it doesn't conform to what makes a function declaration a prototype: by definition, it provides no information on the number and types of the parameters, yet that is what makes a function declaration a prototype. Your interpretation of the standard is in error because of this misunderstanding.

Compilers aren't in violation if they take no action for undefined behaviour (i.e., it is the code that is standard non-conforming), and in this case compilers cannot even take action to emit a warning when relevant parts of the program are compiled separately.

Yes, we definitely agree on the most practically important point. Personally, I don't see people using this much any more, unless they are old-timers who know what they are doing, or newcomers especially from C++ who don't. We don't have to worry about the former, and the latter can easily be informed, like you did in this thread.