what is the output

[Shao Miller]

main()
{
int d=010;
printf("%d",d);
}

please give with explanation

Correct output: 31 Usenet response posts.

Explanation:

 

[Tim Rentsch]

On 7/3/2011 12:32 PM, vinay kumar wrote:
main()
{
int d=010;
printf("%d",d);
}

please give with explanation
[snip]

Also either (1) "semi-undefined" because a C90 int-valued
function returns without returning a value, [snip]

Actually this aspect's behavior is defined; only the termination
status returned to the host environment is undefined. (Or it is
implementation-defined in a freestanding implementation.)

To the first point, that's what I intended to indicate with the
weasel-words "semi-defined." The behavior is undefined if (1) the
caller of main() is written in C, and (2) the caller makes use of the
returned value. If the returned value is not used, there's no problem.
And if the caller is not written in C, then C's rules don't apply.

Reading this reminds me of a quote: "I concede your point -
if things were different, they wouldn't be the same."

Yes, _if_ it were true that what we're looking at is only
part of a program rather than the whole program then these
considerations might come into play. For all we know this
piece comes after an #if 0 ...

However, most who commented on it, including yourself,
responded as though what's presented is an entire program.

In that context, C90 specifically and explicitly defines the
behavior of returning from main() without giving a return
value to say the termination status returned to the host
environment is undefined. Anything beyond that is simply
outside the scope of the C standard, as is true for all
terminations. You might as well say that 'return 0;' from
main() is "semi-defined"; in neither case is there anything
more to say about what happens further, as whatever that may
be is outside the realm of both language and implementation.

To the second point, in a free-standing implementation it is not
possible to predict (from the information given) what output, if any,
is produced. For all we know, printf() computes checksums of its
arguments, combines them into a complex number, and returns the
logarithm thereof after launching the nuclear missiles.

Sorry, I thought it was clear from how the snipping was done
that I was addressing only the one aspect of the program
that the sentence being responded to concerns itself with,
namely, the behavor of returning without using a 'return'
statement.

 

[Tim Rentsch]

You can't take 3 from 2, 2 is less than 3,
so you look at the 4 in the eight's place.
Now that's really four 8's, so you make
it three 8's,

... regroup, and you ...

change an 8 to 8 ones and
add them to the 2 and that gives 1 2 base 8
which is ten base ten and you take away 3 that's 7.

[...]

Right... stanzas two and three I needed to look up, but the
first stanza I did from (much less than perfect) memory...

 

[Tim Rentsch]

Several diagnostics, since
a) main incorrectly has no return type (should be int)

Allowed in C90.

b) printf has no prototype (#include <stdio.h>)

C90 - no diagnostic required (and will probably work
just fine).

c) for pre-C99 compilers, main fails to return a value.

C90 - no diagnostic required, and behavior is defined
(only termination status returned to host environment
is undefined).

 

[Keith Thompson]

Allowed in C90.


C90 - no diagnostic required (and will probably work
just fine).

Right.

But strictly speaking, the behavior is still undefined.
The compiler, upon seeing the call, assumes that printf has been
declared as

int printf(char*, int);

or equivalent; the actual definition is variadic, which means (for
example) that the fimplementation is allowed to use an entirely
different calling sequence.

But in practice, it's going to work on most or all C90
implementations, because any implementation on which it didn't work
would have broken too much existing code. Even C99 implementations
are likely to (have a mode in which they) let it by with a warning.

C90 - no diagnostic required, and behavior is defined
(only termination status returned to host environment
is undefined).

Right. But note that, unlike the phrase "undefined behavior", the
standard doesn't say what an undefined termination status means, so we
have to fall back on the English meanings of the words. The most likely
meaning is that the termination status can be as if main() returned any
arbitrary int value (and the implementation is not required to document
how this value is determined, or even to be consistent about it).

But one could imagine the "termination status" being something other
than an int value -- such as the canonical "suffusion of yellow".

(Since C99 has patched this loophole anyway, we're not going to
see a ruling on this.)

 

[Eric Sosman]

[...]
Reading this reminds me of a quote: "I concede your point -
if things were different, they wouldn't be the same."

Ass.

 

[Morris Keesan]

Several diagnostics, since
a) main incorrectly has no return type (should be int)
b) printf has no prototype (#include <stdio.h>)
c) for pre-C99 compilers, main fails to return a value.

But since main is not declared with a return type, this lack of a return
shouldn't trigger a diagnostic, should it?

 

[John Gordon]

I know I shouldn't do this, but I'm going to take the bait on this
one. How do you figure the output is the "8".

Because a leading zero indicates octal notation instead of decimal.

 

[Shao Miller]

[...]
Reading this reminds me of a quote: "I concede your point -
if things were different, they wouldn't be the same."

Ass.

Some day I'd like to throw a comp.lang.c party. Even the
10-errors-in-5-lines-of-code-no-follow-up-post entities could find
themselves as welcome guests. Then we could all share merry laughter
and memories. See you all there!

 

[Eric Sosman]

But since main is not declared with a return type, this lack of a return
shouldn't trigger a diagnostic, should it?

C99: Yes, because defining a function without specifying a
return type requires a diagnostic. (The "lack of a return" need
not produce a diagnostic, and is in fact well-defined for hosted
environments because of a vile pandering to sloppy programmers.
But the "not declared with a return type" is verboten.)

C90: Implementation's discretion. No diagnostic is required,
but all diagnostics are (as always) permitted. ("Warning: Code was
written on a Thursday. I never could get the hang of Thursdays.")

 

[Todd Carnes]

[snip]

I got the number "8" after I compiled and ran this code on my Linux box
here at home. I just wasn't clear on why the computer produced the
number "8" and not the number "10".

Chad

Someone already told you that a leading zero is used to indicate that you
are using the octal numbering system vice, the decimal system, correct?

What does the octal number 010 equal in the decimal system?

Hint: 010 in the binary system is equal to 2 in the decimal system.

Todd

 

[Todd Carnes]

Correct output: 31 Usenet response posts.

Explanation:

LOL!

 

[Keith Thompson]

C99: Yes, because defining a function without specifying a
return type requires a diagnostic. (The "lack of a return" need
not produce a diagnostic, and is in fact well-defined for hosted
environments because of a vile pandering to sloppy programmers.
But the "not declared with a return type" is verboten.)

In fact it's a syntax error. "main() { ... }" doesn't satisfy
the syntax for a function definition, and a compiler needn't even
recognize it as one. (Probably most C99 compilers use grammars
that recognize C90-style declarations, for the purpose of producing
meaningful error messages.)

C90: Implementation's discretion. No diagnostic is required,
but all diagnostics are (as always) permitted. ("Warning: Code was
written on a Thursday. I never could get the hang of Thursdays.")

Right. In C90, a missing return type is equivalent to an explicit
return type of "int". The declaration is perfectly correct C90
(ignoring an obscure quibble about "main()" vs. "main(void)").

 

[Tim Rentsch]

[...]
Reading this reminds me of a quote: "I concede your point -
if things were different, they wouldn't be the same."

Ass.

You gave a bogus argument, made in an effort to support a
position that is clearly technically wrong. If you want to
make bogus arguments, that's up to you, but if you do you
shouldn't be surprised or outraged to get a response calling
attention to that fact.

 

[Tim Rentsch]

Allowed in C90.


C90 - no diagnostic required (and will probably work
just fine).

Right.

But strictly speaking, the behavior is still undefined.
[snip elaboration]

Yes, I was mainly commenting on the (implicit) claim that
a diagnostic is required, which it is not.

C90 - no diagnostic required, and behavior is defined
(only termination status returned to host environment
is undefined).

Right. But note that, unlike the phrase "undefined behavior", the
standard doesn't say what an undefined termination status means, so we
have to fall back on the English meanings of the words. The most likely
meaning is that the termination status can be as if main() returned any
arbitrary int value (and the implementation is not required to document
how this value is determined, or even to be consistent about it).

But one could imagine the "termination status" being something other
than an int value -- such as the canonical "suffusion of yellow".
[snip C99-related]

If I may summarize, the main point you're making is that a
"termination status that is undefined" could do anything -
any possible behavior might result. And that conclusion is
correct.

However, as far as the C Standard is concerned, it is also true
that there is just as wide a range of possible behaviors if
'return 0;', 'return EXIT_SUCCESS;', or 'return EXIT_FAILURE;'
is done instead. No matter what the termination status is, what
might happen after returning to the host environment could be
anything at all - neither the C Standard nor the implementation
has any control over it or anything to say about it.

An implementation could choose to treat 'main()' returning
without an exit value as being the same as 'main()' doing a
'return EXIT_FAILURE;' (or 'return 0;'), but doing that doesn't
limit what the host environment may do upon a return. At some
level, the point of having the termination status being undefined
when 'main()' doesn't do a return is so that implementations are
free to choose one of these possibilities (or perhaps make no
particular choice at all, which is also their prerogative under
C90).

It is of course possible, in some theoretical sense, that an
operating system could respond to "defined" termination statuses
in a graceful way, and respond to "other" termination statuses
by launching ICBM's or setting the computer on fire. However,
as far as what the Standard says, it is just as possible that
the reverse would hold. So an argument that either of these
is an "anything could happen" situation seems pretty weak,
and practically speaking there is likely to be little if any
difference between them.