This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Is it legal to recurse into main() in C++?
#include <iostream>
using namespace std;
int main() {
static int var = 5;
std::cout << --var;
if(var)
main();
}
gcc compiles the code http://ideone.com/lIp3A . I know that main cannot be used inside main in C++. How come this code compiles?
The code is ill-formed because it violates the shall construct of §3.6.1.3
§3.6.1.3 says :
The function main shall not be used within a program.
The shall construct
A diagnosable rule is defined as (§1.4.1):
The set of diagnosable rules consists of all syntactic and semantic rules in this International Standard except for those rules containing an explicit notation that “no diagnostic is required” or which are described as resulting in “undefined behavior.”
§3.6.1.3 defines a diagnosable rule.
According to §1.4.2:
— If a program contains no violations of the rules in this International Standard, a conforming implementation shall, within its resource limits, accept and correctly execute that program.
— If a program contains a violation of any diagnosable rule, a conforming implementation shall issue at least one diagnostic message, except that
— If a program contains a violation of a rule for which no diagnostic is required, this International Standard places no requirement on implementations with respect to that program.
Conclusion
A compiler is free to do whatever it wants to do. Try the same code on Comeau Online (a more conforming compiler).
I get this error
"function "main" may not be called or have its address taken"
Related
I fear this is again a question about interpreting the ISO/IEC 14882 (the C++ standard) but:
Is calling main from the program e.g. my calling main() recursively from main not at least implementation defined behavior? (Update: I imply later ill-formed not implementation defined, also not UB, see below and answer)
6.9.3.1 [basic.start.main] states
3 The function main shall not be used within a program. The linkage (6.6) of main is implementation-defined...
The consensus seems to be undefined behavior (UB). The documentation of MSVC also points towards UB, the one of gcc also implicitly denies implementation-defined behavior. It can not be [defns.unspecified] unspecified behavior since I would interpret shall not as ill-formed.
However, despite the implementations, to my interpretation is should not be UB but as 4.1 [intro.compliance] states
1 The set of diagnosable rules consists of all syntactic and semantic rules in this document except for those
rules containing an explicit notation that “no diagnostic is required” or which are described as resulting in
“undefined behavior”.
...
(2.2) — If a program contains a violation of any diagnosable rule or an occurrence of a construct described in
this document as “conditionally-supported” when the implementation does not support that construct,
a conforming implementation shall issue at least one diagnostic message.
For me the reasoning seems clear
tl;dr
calling main implies the program contains a violation of the rule of [basic.start.main]
[basic.start.main] does not state calling/use is UB or a diagnostic is not required
is an element of "diagnosable rules" as per [intro.compliance]
[intro.compliance] 2.2 states violation of any diagnoseable rule must be issued at least one diagnostic message
Since 3. and 4. the usage of main shall issue at least one diagnostic message
Since 5. 1. is not UB
Since neither gcc,MSVC or clang issue an error or warning but compile, all major implementations are not compliant
Of course since 7. I feel again in the Don Quixote scenario i.e. being wrong, so I would appreciate if someone could enlighten me about my mistake. Otherwise, there are standard defects, aren't there?
I think your analysis is correct: calls to main are ill-formed.
You have to pass the -pedantic flag to make GCC and Clang conform. In that case, Clang says
warning: ISO C++ does not allow 'main' to be used by a program [-Wmain]
and GCC says
warning: ISO C++ forbids taking address of function '::main' [-Wpedantic]
But they allow calls to main as an extension. The standard permits such an extension, since it doesn't change the meaning of any conforming programs.
C++03 Standard defines well-formed program (1.3.14 [defns.well.formed]) as
a C++ program constructed according to the syntax rules, diagnosable semantic rules, and the One Definition Rule (3.2)
It further defines an ill-formed program (1.3.4 [defns.ill.formed]) as
input to a C++ implementation that is not a well-formed program (1.3.14)
and the Standard is full of statements such as "if X then the program is ill-formed" for example (2.13.1/3):
A program is ill-formed if one of its translation units contains an integer literal that cannot be represented by any of the allowed types.
Yet I haven't found what the C++ implementation is required to do with ill-formed programs.
Suppose I have an ill-formed program. Now what?
Is the C++ implementation required to do something specific when it encounters an ill-formed program or is the C++ implementation behavior just undefined?
Is the C++ implementation required to do something specific when it encounters an ill-formed program or is the C++ implementation behavior just undefined?
If the Standard does not specify otherwise, an implementation should emit a diagnostic message (error or warning). However, for some violations the Standard explicitly specifies that no diagnostic is required. In this case, the program is ill-formed, but implementations are not required to tell the user - usually, because doing so in the general case would be too difficult.
Concerning the One Definition Rule, for example, see Paragraph 3.2/4 of the C++11 Standard:
Every program shall contain exactly one definition of every non-inline function or variable that is odr-used
in that program; no diagnostic required.
Regarding the requirements on implementations when encountering a violation of a rule, Paragraph 1.4/2 specifies:
[...]
— If a program contains no violations of the rules in this International Standard, a conforming implementation
shall, within its resource limits, accept and correctly execute that program.
— If a program contains a violation of any diagnosable rule or an occurrence of a construct described in
this Standard as “conditionally-supported” when the implementation does not support that construct,
a conforming implementation shall issue at least one diagnostic message.
— If a program contains a violation of a rule for which no diagnostic is required, this International
Standard places no requirement on implementations with respect to that program.
Also relevant is Paragraph 1.4/1, which explains what is meant by "diagnosable rules" in the Paragraph quoted above:
The set of diagnosable rules consists of all syntactic and semantic rules in this International Standard except
for those rules containing an explicit notation that “no diagnostic is required” or which are described as
resulting in “undefined behavior.”
So to sum it up: if an ill-formed program contains a diagnosable violation for which the Standard does not explicitly specify "no diagnostic required", conforming implementations should emit a diagnostic.
Quoting [intro.compliance]§2:
If a program contains no violations of the rules in this International Standard, a conforming implementation shall, within its
resource limits, accept and correctly execute that program.
If a program contains a violation of any diagnosable rule or an occurrence of a construct described in this Standard as
“conditionally-supported” when the implementation does not support
that construct, a conforming implementation shall issue at least one
diagnostic message.
If a program contains a violation of a rule for which no diagnostic is required, this International Standard places no requirement on
implementations with respect to that program.
I haven't found any other relevant passages in the standard. If we combine this with [defns.undefined]:
undefined behavior
behavior for which this International Standard imposes no requirements
[ Note: Undefined behavior may be expected when this International
Standard omits any explicit definition of behavior or when a program
uses an erroneous construct or erroneous data. Permissible undefined
behavior ranges from ignoring the situation completely with
unpredictable results, to behaving during translation or program
execution in a documented manner characteristic of the environment
(with or without the issuance of a diagnostic message), to terminating
a translation or execution (with the issuance of a diagnostic
message). Many erroneous program constructs do not engender undefined
behavior; they are required to be diagnosed. -end note ]
I'd say we arrive at "issue a diagnostic message and further the behaviour is undefined," because the standard doesn't say anything more about it.
(First of all, sorry for my English)
The Standard, in §1.4.2 says:
If a program contains a violation of any diagnosable rule [...] a conforming implementation shall issue at least one diagnostic message.
The definition of a ill-formed program is "a program that is not well formed" (§1.3.9), and a well-formed program is (§1.3.26):
C++ program constructed according to the syntax rules, diagnosable semantic rules, and the One Definition Rule
So, a ill-formed program does implicitly violate "some" rule. If a rule R has the following structure:
If a program has property P, it is an ill-formed program.
When a program has such property P, it does implicitly violate a rule (by definition of an ill-formed program), although it isn't clear which rule is the one which are being violated, since R itself doesn't (from a strictly logical point of view).
The only relevant quote I could find says that an implementation is required to diagnose an ill-formed program, but it can finish compiling it:
1.4 Implementation compliance [intro.compliance]
8) A conforming implementation may have extensions (including additional
library functions), provided they do not alter the behavior of any
well-formed program. Implementations are required to diagnose programs
that use such extensions that are ill-formed according to this
International Standard. Having done so, however, they can compile and
execute such programs.
While reading the C++ standard, one often sees designations like "... ill-formed, no diagnostic required". A (random) example can be found in 13.8.1/17:
The class S1::Inner1 is ill-formed, no diagnostic required, because
it has no valid specializations.
Where can one find an opposite normative language in the standard, which would prescribe a diagnostic for an ill-formed program?
What you are looking for is [intro.compliance]/1
The set of diagnosable rules consists of all syntactic and semantic rules in this document except for those rules containing an explicit notation that “no diagnostic is required” or which are described as resulting in “undefined behavior”.
It is then followed up with [intro.compliance]/2
If a program contains a violation of any diagnosable rule or an occurrence of a construct described in this document as “conditionally-supported” when the implementation does not support that construct, a conforming implementation shall issue at least one diagnostic message.
which guarantees that if you break one of the diagnosable rules you'll get a diagnostic message.
Stephen Prata in his book C++ Primer Plus [p 31] says :
Many existing programs use the classic C function header instead:
main() // original C style
Under classic C, omitting the return type
is the same as saying that the function is type int. However, C++ has
phased out that usage.
However The C++11 draft 3.6.1->2 says
An implementation shall not predefine the main function. This function
shall not be overloaded. It shall have a return type of type int, but
otherwise its type is implementation-defined.
Test Result
$ g++ -Werror=pedantic MainCheck.cpp -o MainCheck
MainCheck.cpp:3:6: error: ISO C++ forbids declaration of ‘main’ with no type [-Werror=pedantic]
main()
$ # also means g++ don't conform to the standard
confirms that what Mr. Prata said is true when it comes to C++ standard.
Is there a clause in the C++11 draft that discourages the use of :
main() // that is without return type.
Is
It shall have a return type of type int
itself such a clause?
See also What should main() return in C and C++?
ISO/IEC 14882:1998 contains:
§7 Declarations
¶7 Only in function declarations for constructors, destructors, and type conversions can the decl-specifier-seq
be omitted.78)
and footnote 78 says:
The “implicit int” rule of C is no longer supported.
The same statements are in ¶9 and footnote 89 in the C++11 standard.
So, main() declared without the return type has never been a part of standard C++, but it was allowed roughly up until C++98 standard was created (and probably a bit longer for reasons of backwards compatibility).
If you look in Stroustrup's "Design and Evolution of C++" (published 1994), §2.8 The C Declaration Syntax says:
Allowing the type specifier to be omitted (meaning int by default) also led to complications. … The negative reaction to changes in this area from users was very strong. … I backed out the change. I don't think I had a choice. Allowing that implicit int is the source of many of the annoying problems with the C++ grammar today. … Finally, ten years later, the C++ ANSI/ISO standard committee has decided to deprecate implicit int. That means we may get rid of it in another decade or so.
Implicit int types were disallowed in all C++ standards, i.e., it wasn't allowed in C++98. It isn't anything new in C++11. There wasn't any exception for main() with respect to the declaration of the function. Also, the implicit int rule applied to all declarations not just to main().
The relevant clause in the C++ standard is 7 [dcl.dcl] paragraph 11:
Only in function declarations for constructors, destructors, and type conversions can the decl-specifier-seq
be omitted.94
94) The “implicit int” rule of C is no longer supported.
I don't have easy access to the C++98 standard right now but C++03 definitely has the same statement. The only difference is that it is in paragraph 7 and the footnote is "79" instead of "94".
C's implicit int rule was part of C++ for a while prior to the first standard but got removed at some point. Compilers may accept programs omitting the type as an extension but I think they are required to emit a diagnostic. Whether that means much is a separate question as it is long established that writing a single \r at the start of a line would meet that requirement.
What is there and what will remain is the odd exception that program execution can flow off the end of main() without a return statement: it is assumed that mandating a return statement in main() would break existing code.
The statement
It shall have a return type of type int
doesn't state anything about how the function acquires its return type. It only states what the return type shall be.
This is what the working draft says about the main function.
Excerpts follow.
3.6.1/2
An implementation shall not predefine the main function. This function shall not be overloaded. Its type shall have C++ language linkage and it shall have a declared return type of type int, but otherwise its type is implementation-defined. An implementation shall allow both
a function of () returning int and
a function of (int, pointer to pointer to char) returning int
as the type of main
3.6.1/5:
A return statement in main has the effect of leaving the main function [...] If control flows off the end of the compound-statement of main, the effect is equivalent to a return with operand 0
So, the standard says that the main function shall have one of the following types:
int()
int(int, char **)
Being the main function a function, I guess it follows also the rules in 8.3.5.
The question would become thus: can I omit the return type from a function definition? Does the standard allow me to do that?
The answer is no, indeed.
It is not required by the standard for the main to explicitly return. If return statement is missing, compiler simply puts:
return 0;
at the end. This rule doesn't apply to other functions.
In C, default return type of any function was int if not provided by programmer, for example:
get() // int assumed
{
return 10;
}
C++ standard requires that you must specify the return type. Above code will not compile in C++ compiler. C90 allowed implicit int, C99 disallows implicit int.
For example, the famous words (§3.2/1)
No translation unit shall contain more than one definition of any variable, function, class type, enumeration
type, or template.
I believe "shall" requirements are to be interpreted as though they are implicitly followed by "otherwise the program is ill-formed" unless otherwise specified. However, others claim that "shall" instead means "otherwise the behavior is undefined".
In every case I've come across in the standard in which a "shall" requirement was not followed by something like "otherwise the behavior is undefined" or "no diagnostic required", the rule it occurred in was one that is obviously diagnosable and is diagnosed by all compilers I know of (the above paragraph being an example). That's why I believe it means "otherwise the program is ill-formed", i.e., a diagnostic is required.
Anyway, those are just my thoughts. I'd appreciate an authoritative answer.
Yes, to be well-formed, the program must follow the One Definition Rule that you've quoted in the question (§1.3.26):
well-formed program
C++ program constructed according to the syntax rules, diagnosable semantic rules, and the One Definition Rule (3.2).
The other diagnosable rules are specified as (§1.4):
1.4 Implementation compliance [intro.compliance]
1 The set of diagnosable rules consists of all syntactic and semantic rules in this International Standard except
for those rules containing an explicit notation that “no diagnostic is required” or which are described as resulting in “undefined behavior.”
2 Although this International Standard states only requirements on C++ implementations, those requirements are often easier to understand if they are phrased as requirements on programs, parts of programs, or execution of programs. Such requirements have the following meaning:
— If a program contains no violations of the rules in this International Standard, a conforming implementation shall, within its resource limits, accept and correctly execute2 that program.
— If a program contains a violation of any diagnosable rule or an occurrence of a construct described in this Standard as “conditionally-supported” when the implementation does not support that construct, a conforming implementation shall issue at least one diagnostic message.
— If a program contains a violation of a rule for which no diagnostic is required, this International Standard places no requirement on implementations with respect to that program.[emphasis added]
And yes, as noted in the second bullet point, if a diagnosable rule is violated, a diagnostic is required.
In addition to #JerryCoffin's answer, there is also ISO/IEC Directives
Part 2 (that governs all ISO/IEC documents, including the C++ Standard), in particular Annex H Verbal forms for the expression of provisions
The verbal forms shown in Table H.1 shall be used to indicate
requirements strictly to be followed in order to conform to the
document and from which no deviation is permitted.
shall:
is to,
is required to,
it is required that,
has to,
only … is permitted,
it is necessary
shall not:
is not allowed [permitted] [acceptable] [permissible],
is required to be not
is required that … be not
is not to be
So a violation of a "shall" requirement makes a program ill-formed. The diagnostic issues have been answered elsewhere.