Reputation: 1307
Before anyone may mark it duplicate of related questions. I emphasize I DO have read all those questions. But I still have some interrogations(yep, some little pedantic :) )
For C
Some conclusions:
1. In C89(C90), this is _undefined_ .
2. In C99(or C11), a type of int is madatory; control flow reached the closing }
will return a value of 0.
Here comes my interrogations.
In c89, I have found nothing about undefined, but unspecified?
Detail: The related parts in C89 are 5.1.2.2.1 Program startup and 5.1.2.2.3 Program termination (NOTE : both are under the 5.1.2.2 Hosted environment section, within which our later discussion is limitted)
Cite: -- 5.1.2.2.3 Program termination --
A return from the initial call to the main function is
equivalent to calling the exit function with the value
returned by the main function as its argument.10 If the }
that terminates the main function is reached, the
termination status returned to the host environment is
unspecified.
Just note that part: If the } that terminates ... , it clearly says
that if we omit the return type - thus the } will be reached at -
the termination status is unspecified
According the definition of the standard of undefined and unspecified, Should I say that it gives unspecified value since whatever it return is a legal int value, but the consequese is undefined-we could not predict what value will lead to what catastrophic consequese?
In c99, a type of int is madatory, but gcc --std=c99
given a test without int type(no return type actually) gives only waring:return type of ‘main’ is not ‘int’ ,but not error ?
Detail: the related parts are the same as that in c89.
Cite: -- 5.1.2.2.1 Program startup --
It shall be defined with a return type of int and ...
and -- 4. Conformance --
1. In this International Standard, ‘‘shall’’ is to be interpreted as a requirement on an implementation or on a program; conversely, ‘‘shall not’’ is to be interpreted as a
prohibition.
So shall should be interpreted as madatory in this standard, why gcc with swith --std=c99 violated this?
Upvotes: 1
Views: 1682
Reputation: 490108
C89/90 still has the implicit int rule, so main()
is equivalent to int main()
. By leaving off the return type, you've implicitly defined the return type as int
. Some may consider this sloppy, but it's strictly conforming (i.e., involves no implementation defined, undefined or unspecified behavior).
For C99, the implicit int
rule has been removed, so main()
isn't defined. However, a compiler is only required to "issue a diagnostic" upon encountering a violation of a Shall
or Shall not
clause -- it's still free to continue compiling after issuing the diagnostic. Exactly what constitutes a diagnostic is implementation defined. As such, all that's needed for gcc to conform in this respect is documentation to say that the warning it issues is to be considered a diagnostic.
Edit: "implicit int
" in the C89/90 standard isn't really a single rule in a single place -- it's spread around in a couple of places. The primary one is §6.5.2.1, where it says:
--
int
,signed
,signed int
, or no type specifiers
This is part of a list, where all the items on each line of the list are considered equivalent, so this is saying that (unless otherwise prohibited) lack of a type specifier is equivalent to specifying (signed) int
.
For function parameters, there's a separate specification (at §6.7.1) that: "Any parameter that is not declared has type int
."
Upvotes: 4
Reputation: 213809
It would seem that this is some sort of C90 standard reference mistake. I have no idea whether the document you link to is equivalent to the actual ISO C90 standard or not.
Apparently, this particular issue has changed from undefined, to unspecified, to well-defined over the years.
In early drafts of ANSI-C "for the X3.J11 working group", you will find the following text:
2.1.2.2 Hosted environment
"Program termination"
A return from the initial call to the main function is equivalent to calling the exit function with the value returned by the main function as its argument. If the main function executes a return that specifies no value, the termination status returned to the host environment is undefined.
Upvotes: 0
Reputation:
Just note that part: If the } that terminates ... , it clearly says that if we omit the return type
No, it doesn't. It says what happens when you omit the return exitStatus;
from the end of main()
.
According the definition of the standard of ** undefined ** and unspecified, Should I say that it gives unspecified value since whatever it return is a legal int value, but the consequese is undefined-we could not predict what value will lead to what catastrophic consequese.
No. It means that you don't know what the return status code of your program will be. The behavior is, however, not undefined: your program terminates. With what kind of result code, that's a different question.
[...] gives only waring: return type of ‘main’ is not ‘int’, but not error?
That's how it's implemented. In old C (C89) - and with some newer compilers as well - if you omit the return type of a function, it is assumed to be int
(so even the warning looks a bit problematic).
So shall should be interpreted as madatory in this standard, why gcc with swith --std=c99 violated this?
Probably yes. Note that GCC is a non-conformant implementation except if you use -ansi -pedantic
, so in theory, any program compiled without these flags has undefined behavior. But that's theory...
Upvotes: 0
Reputation: 78903
Even in case of a constraint violation, the only thing a C compiler must issue is a "diagnostic". It is then allowed to continue and to produce an executable program.
Upvotes: 0