Well... ok... will do the same thing as int main(void), but to declare a function without arguments, in C, is the same as telling the compiler it must accept ANY number of arguments in the function call, but ignore them.
For example:
This function can be called as:Code:int f() { return 0; }
And the compiler is ok with it... Try it...Code:x = f(); x = f(1); x = f(1, "fred"); x = f(1, "fred", 3.14, NULL); ...
In C++ the empty arguments list means 'void'.
That is true for a function declaration that is not also a function definition, but in a function definition, an empty parameter identifier list declares that the function has no parameters, i.e., it is equivalent to having void as the parameter type list. In your example, the function named f is defined as such, hence it has no parameters, so "the compiler is ok with it" is not guaranteed to be true, even if it happens to be true for the compiler with which you tested your code.Originally Posted by flp1969
See:
Also, while an empty parameter identifier list in a function declaration does imply that the compiler "must accept ANY number of arguments in the function call", because there is no parameter type list, the forward declaration is not a function prototype, hence failure to make the call match the function definition results in undefined behaviour, so in your example, the function calls other than the first result in undefined behaviour (apart from the fact that the declaration of f is also its definition). Consequently, a compiler doing whole program static analysis might be able to discover this mismatch, and hence emit a diagnostic despite your claim that "the compiler is ok with it".
Last edited by laserlight; 03-21-2019 at 05:30 AM.
Look up a C++ Reference and learn How To Ask Questions The Smart Way
6.11.7 (FUTURE language defintions) states that "The use of function declarators with empty parentheses (not prototype-format parameter
type declarators) is an obsolescent feature". It means the compiler follows previous standards (C90? ANSI?) and still accepts this declarations (and definitions)...
As far as I know, there is no provision for "unspecified" or "undefined behavior" on Annex J for this type of calls. And 6.5.6.3 (not 6.7.6.3) states clearly, in both cases, declarations and definitions, will behave as if there is no arguments. But says nothing about the function call. It is implied that all arguments will be discarded (as it is!).
Yes... I poorly choose the word "must". I meant this behavior is observed in every compiler I know (including the old Turbo-C for MS-DOS and old copilers for some old Unix flavors).
A simple test:
Where are the warnings or errors?Code:$ gcc -std=c99 -pedantic -xc -Wall -Wextra -include stdio.h - <<EOF int f(){return -1;} int main(){printf("%d\n", f(1,2,3));} EOF $ ./a.out -1
Last edited by flp1969; 03-21-2019 at 09:17 AM.
Because in C, int f() is synonymous with int f(...), except that saying that is invalid syntax.
In the same vein that historic C assumed everything was an int, so
was also implicitly declaring f as returning int.Code:f(){return -1;}
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
Do you know what "undefined behavior" is?
It certainly doesn't require errors or warnings.
A little inaccuracy saves tons of explanation. - H.H. Munro
Yep... show me where, in the standard, this type of CALL is undefined behavior... Clearly, the declaration and definition isn't (it is "obsolete", by 6.11.7, but not "undefined")...
This example is my atempt to refute @laserlight conclusion:
... Consequently, a compiler doing whole program static analysis might be able to discover this mismatch, and hence emit a diagnostic despite your claim that "the compiler is ok with it.
Last edited by flp1969; 03-21-2019 at 09:49 AM.
I'm quoting from C99, not C11, as I don't have a copy of C11 (yeah, I know I could look up a late draft copy, but it feels a little dishonest to cite from a standard when you're actually citing from a late draft of that standard), but these are the kind of things that are unlikely to change significantly, and from what I am aware, parameter identifier lists haven't actually been removed from C11, despite being declared obsolescent in C99... but I guess it wasn't a priority since other than empty parameter identifier lists, I have pretty much never seen parameter identifier lists used these days.
It is undefined behaviour as implied by the clause on function calls (duh), but if you want an explicit listing, it is also listed in the annex on undefined behaviour:
From what I see, the first of the items I extracted applies: the definition of f is not "a declaration of a function that declares the types of its parameters" since it is a declaration with a parameter identifier list rather than a parameter type list, hence no function prototype is in scope. The number of arguments does not equal the number of parameters for the function calls other than the first. Therefore, the behaviour is undefined.
Incidentally, 6.5.2.2 is the clause on function calls in C99, so you could look up the relevant clause in C11. The paragraph that starts with "If the expression that denotes the called function has a type that does not include a prototype" would be the relevant one. The long paragraph might have been reworked into two or three in C11 though, but it should be around there somewhere and say pretty much the same thing since it is unlikely there would have been any need to actually get it to say something else.
Combined with what you observed about function identifier lists being an obsolescent feature, I'm inclined to discourage the use of empty parameter identifier lists in favour of void as the identifier type list, even for function definitions, so I think that it is good that you brought this up, but I think that it is not so good to present its misuse as being okay (although hopefully newbies will realise that even if it is actually okay, it makes no sense to misuse it in practice).
EDIT:
There's little incentive for modern compiler authors to change this though: without a prototype, if you want to warn instead of ignore, you need to refer to the function definition, but there's a good chance that that is in a library file, maybe even a dynamically linked one! Coupled with non-prototype function declarations being both obsolescent and seeing reduced use in practice, it doesn't seem all that worth it to aid programmers who insist on the old style, and after all no diagnostic is required even when you could have the compiler emit one.
Last edited by laserlight; 03-21-2019 at 12:50 PM.
Look up a C++ Reference and learn How To Ask Questions The Smart Way
Thanks, @laserlight...
I apologize for citing 6.5.6.3. Even on C11 spec it is wrong...
Seems to me these undefined behaviors are related to functions "without a function prototype in scope". That's not what my example demonstrates... The "spirit" of these 3 entries is where there is a call without prototyping on the same module. Like:
This is, of course, is an undefined behavior, since the compiler doesn't know the return type or if the function requires arguments...Code:#include <stdio.h> // f() does not have a prototype "in scope" here. int main(void) { printf( "%d\n", f() ); }
Anyway, I'm not saying this behavior is a good thing or if it is useful or desirable. Quite opposite, I find this very strange, but the standard allows it. It means, for me, only that empty arguments list (and prototypes without identifiers are optional, by the standard!) is semantically different from C++.
I don't like empty list of arguments, even on C++, to functions with no arguments.
By the way... puts a prototype "in scope" with an empty argument list, and the compiler will not complain:
In conformity to the standard!Code:$ gcc -xc -std=c99 -pedantic -Wall -Wextra -include stdio.h -c -o test.o - <<EOF int f(); // prototype in scope! int main(){printf("%d\n", f());} EOF $
No, a prototype of a function is "a declaration of a function that declares the types of its parameters". That's why when you cited the part about "The use of function declarators with empty parentheses" being an obsolescent feature, it was noted "not prototype-format parameter type declarators". In other words, this function declaration is not a function prototype:
Code:int f();
Look up a C++ Reference and learn How To Ask Questions The Smart Way
As specified in the grammar, item 6.7.5, and Annex A [A.2.1 (Expressions)], the identifiers list is optional. So int f(); is a function prototype. An obsolete construction, but valid.
6.7.5.3 §3: "An identifier list in a function declarator that is not part of a definition of that function
shall be empty."
Last edited by flp1969; 03-21-2019 at 05:29 PM.
A prototype has a parameter type list (in which the identifier names are optional), not a parameter identifier list (which is what the syntax says is optional).
If indeed it is a prototype, explain: "The use of function declarators with empty parentheses (not prototype-format parameter type declarators) is an obsolescent feature". Why would the standard say that "function declarators with empty parentheses" are "not prototype-format parameter type declarators" when function declarations with such declarators are prototypes?
Look up a C++ Reference and learn How To Ask Questions The Smart Way
This is cited on 6.11.6, "Future language directions" (not "in the present" on C99 standard!)... and still in the future for C11 standard!
Last edited by flp1969; 03-21-2019 at 05:42 PM.
Eh, that is an incorrect interpretation on two counts:
1. The standard isn't saying "that function declarators with empty parentheses are prototype-format parameter type declarators is an obsolescent feature". No, it is saying that "the use of function declarators with empty parentheses is an obsolescent feature". The note about "not prototype-format parameter type declarators" is used to clarify that this does not pertain to "prototype-format parameter type declarators".
2. The standard does not say "will be an obsolescent feature", but "is an obsolescent feature". It pertains to what is its status now, i.e., what it states is for the present. It is a future language direction because it warns that in the future, obsolescent features could be removed.
Look up a C++ Reference and learn How To Ask Questions The Smart Way
