what is the output of this program?

[Kenny O'Clock]

This came up in a job interview, what is the output of the program
below? I tried to compile and run it myself, but my compiler (lcc-win32)
aborts with this errors....

Warning test2.c: 3 old-style function definition for 'main'
Warning test2.c: 3 missing prototype for 'main'
Warning test2.c: 3 '
Error test2.c: 3 compiler error in d:\lcc\mc71\typ es.c--assertion failure at line 868
Error c:\test\test2.c 3 Compiler error (trap). Stopping compilation
1 error

Here is the program....

1: #include <stdio.h>
2: void main()
3: {
4: int C = 0;
5: printf("C %s C++\n", C == C++ ? "==" : "!=");
6: }

I don't even have a d:\lcc\mc71\ folder on my computer!
Please help, I don't know what to do anymore!!!

[Walter Roberson]

Re: what is the output of this program?

In article <3167502.MWURcN yiUU@aioe.org>,
Kenny O'Clock <nospam@nospam. invalidwrote:

>This came up in a job interview, what is the output of the program
>below?

1: #include <stdio.h>
2: void main()
3: {
4: int C = 0;
5: printf("C %s C++\n", C == C++ ? "==" : "!=");
6: }

In the expression C == C++,
the variable being incremented is accessed more than once between
sequence points ("except to determine the value to be stored").
That is not permitted, so the result could be anything.
-Usually- the result would be either "C == C++" or "C != C++"
printed out (dependant on the compiler), but the program
could segfault... or, like you found, the -compiler- could fault.
--
"And that's the way it is." -- Walter Cronkite

[Pietro Cerutti]

Re: what is the output of this program?

Kenny O'Clock wrote:

This came up in a job interview, what is the output of the program
below? I tried to compile and run it myself, but my compiler (lcc-win32)
aborts with this errors....
>
Warning test2.c: 3 old-style function definition for 'main'
Warning test2.c: 3 missing prototype for 'main'
Warning test2.c: 3 '
Error test2.c: 3 compiler error in d:\lcc\mc71\typ es.c--assertion failure at line 868
Error c:\test\test2.c 3 Compiler error (trap). Stopping compilation
1 error
>
Here is the program....
>
1: #include <stdio.h>
2: void main()
3: {
4: int C = 0;
5: printf("C %s C++\n", C == C++ ? "==" : "!=");
6: }
>
I don't even have a d:\lcc\mc71\ folder on my computer!
Please help, I don't know what to do anymore!!!
>

In addition to what Walter said, I would like to point you to question
3.2 of the c.l.c FAQ, at http://c-faq.com/expr/evalorder2.html.

--
Pietro Cerutti

[Walter Roberson]

Re: what is the output of this program?

In article <OLGdnY9fnLuybK DVnZ2dneKdnZydn Z2d@giganews.co m>,
Pietro Cerutti <gahr_SPAM_gahr _ME_chwrote:

>Kenny O'Clock wrote:

> 5: printf("C %s C++\n", C == C++ ? "==" : "!=");

>In addition to what Walter said, I would like to point you to question
>3.2 of the c.l.c FAQ, at http://c-faq.com/expr/evalorder2.html.

Though the impact of that question is a bit reduced because there -is-
a sequence point after the evaluation of C == C++ . That confines
the section of undefined behaviour to be relatively small compared
to typical expressions we see that mix variable accesses with
++ or -- .
--
"Nothing recedes like success." -- Walter Winchell

[dj3vande@csclub.uwaterloo.ca.invalid]

Re: what is the output of this program?

In article <g1l7jg$aln$1@c anopus.cc.umani toba.ca>,
Walter Roberson <roberson@ibd.n rc-cnrc.gc.cawrote :

>In article <OLGdnY9fnLuybK DVnZ2dneKdnZydn Z2d@giganews.co m>,
>Pietro Cerutti <gahr_SPAM_gahr _ME_chwrote:

>>Kenny O'Clock wrote:

>

>> 5: printf("C %s C++\n", C == C++ ? "==" : "!=");

>

>>In addition to what Walter said, I would like to point you to question
>>3.2 of the c.l.c FAQ, at http://c-faq.com/expr/evalorder2.html.

>
>Though the impact of that question is a bit reduced because there -is-
>a sequence point after the evaluation of C == C++ . That confines
>the section of undefined behaviour to be relatively small compared
>to typical expressions we see that mix variable accesses with
>++ or -- .

Relatively small, perhaps, but still large enough to include all of the
accesses to C in that line of code.


dave

--
Dave Vandervies dj3vande at eskimo dot com
My burning question is this:
"Why do you have some perverse desire to lie to fprintf()?"
--Dann Corbit in comp.lang.c

[Richard Heathfield]

Re: what is the output of this program?

Walter Roberson said:

In article <OLGdnY9fnLuybK DVnZ2dneKdnZydn Z2d@giganews.co m>,
Pietro Cerutti <gahr_SPAM_gahr _ME_chwrote:

>>Kenny O'Clock wrote:

>

>> 5: printf("C %s C++\n", C == C++ ? "==" : "!=");

>

>>In addition to what Walter said, I would like to point you to question
>>3.2 of the c.l.c FAQ, at http://c-faq.com/expr/evalorder2.html.

>
Though the impact of that question is a bit reduced because there -is-
a sequence point after the evaluation of C == C++ . That confines
the section of undefined behaviour to be relatively small compared
to typical expressions we see that mix variable accesses with
++ or -- .

Firstly, because the Standard imposes no limits on the implementation with
regard to undefined behaviour, the wayward effect of C == C++ is not
limited to the "section" of code within which it occurs.

Secondly (and I only mention it because nobody else has in the five replies
that I've seen), the program exhibits undefined behaviour in another way,
too, because the return type of main is incorrect.

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Joachim Schmitz]

Re: what is the output of this program?

Richard Heathfield wrote:

Walter Roberson said:
>

>In article <OLGdnY9fnLuybK DVnZ2dneKdnZydn Z2d@giganews.co m>,
>Pietro Cerutti <gahr_SPAM_gahr _ME_chwrote:

>>Kenny O'Clock wrote:

>>

>>> 5: printf("C %s C++\n", C == C++ ? "==" : "!=");

>>

>>In addition to what Walter said, I would like to point you to
>>question
>>3.2 of the c.l.c FAQ, at http://c-faq.com/expr/evalorder2.html.

>>
>Though the impact of that question is a bit reduced because there
>-is- a sequence point after the evaluation of C == C++ . That
>confines
>the section of undefined behaviour to be relatively small compared
>to typical expressions we see that mix variable accesses with
>++ or -- .

>
Firstly, because the Standard imposes no limits on the implementation
with regard to undefined behaviour, the wayward effect of C == C++ is
not limited to the "section" of code within which it occurs.
>
Secondly (and I only mention it because nobody else has in the five
replies that I've seen), the program exhibits undefined behaviour in
another way, too, because the return type of main is incorrect.

And win-lcc properly warns about this...

Bye, Jojo

[Richard Heathfield]

Re: what is the output of this program?

Joachim Schmitz said:

Richard Heathfield wrote:

<snip>

>Secondly (and I only mention it because nobody else has in the five
>replies that I've seen), the program exhibits undefined behaviour in
>another way, too, because the return type of main is incorrect.

>
And win-lcc properly warns about this...

Implementations are not obliged to diagnose incorrect signatures for main.
If they choose to do so, however, it would be good if they could come up
with some decent diagnostic text. The text given is: "old-style function
definition for 'main'". In fact, there's nothing "old-style" about the
function definition. The problem lies with the return type, and void main
isn't old-style - it's simply *wrong*.

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Martin]

Re: what is the output of this program?

On Wed, 28 May 2008 23:52:36 +0100, Kenny O'Clock <nospam@nospam. invalid
wrote:

This came up in a job interview, what is the output of the program
below?
[...]
1: #include <stdio.h>
2: void main()
3: {
4: int C = 0;
5: printf("C %s C++\n", C == C++ ? "==" : "!=");
6: }

I'm sure from the responses you've had you now realise that the program is
an example of how not to write C. I would send the code back to the
interviewers, annotated in red with the problems and explain to them why
it is bad. Maybe (and it's a big maybe) the author *knew* what a load of
tripe the code is and that was part of the test.

Several years ago at interview I was shown some (production) C code and I
pointed out that the use of memcpy for overlapping buffers was undefined..
The interviewer was convinced that memcpy was safe to use it and that
memmove was the unsafe one. Anyway, after the interview, I wrote them a
letter declining a second interview and provided them an extract from the
C Standard where it says memmove must work properly even when its operands
overlap.

--
Martin

[Joachim Schmitz]

Re: what is the output of this program?

Richard Heathfield wrote:

Joachim Schmitz said:
>

>Richard Heathfield wrote:

>
<snip>
>

>>Secondly (and I only mention it because nobody else has in the five
>>replies that I've seen), the program exhibits undefined behaviour in
>>another way, too, because the return type of main is incorrect.

>>
>And win-lcc properly warns about this...

>
Implementations are not obliged to diagnose incorrect signatures for
main. If they choose to do so, however, it would be good if they
could come up with some decent diagnostic text. The text given is:
"old-style function definition for 'main'". In fact, there's nothing
"old-style" about the function definition. The problem lies with the
return type, and void main isn't old-style - it's simply *wrong*.

The empty parens are old style, vs. main(void).

[Richard Bos]

Re: what is the output of this program?

"Joachim Schmitz" <nospam.jojo@sc hmitz-digital.dewrote :

Richard Heathfield wrote:

Joachim Schmitz said:

Implementations are not obliged to diagnose incorrect signatures for
main. If they choose to do so, however, it would be good if they
could come up with some decent diagnostic text. The text given is:
"old-style function definition for 'main'". In fact, there's nothing
"old-style" about the function definition. The problem lies with the
return type, and void main isn't old-style - it's simply *wrong*.

The empty parens are old style, vs. main(void).

No, they're not. void wasn't in K&R1 at all; so void main() is an _ISO_
declaration, of a function returning nothing (which is wrong for main())
and taking an unspecified number of arguments. If it had been an
old-style declaration, there would have been no void on either side; it
would have been either

main()
{ ....

(which, due to the default int, is correct, although bad style, for a
main() which takes no command line arguments) or

main()
int argc;
char **argv;
{ ....

Neither of those should, of course, be used today, except when faced
with an overwhelming necessity of porting to outdated systems.

Richard

[christian.bau]

Re: what is the output of this program?

On May 29, 10:44 am, Martin <m...@b.cwrot e:

Several years ago at interview I was shown some (production) C code and I
pointed out that the use of memcpy for overlapping buffers was undefined.
The interviewer was convinced that memcpy was safe to use it and that
memmove was the unsafe one. Anyway, after the interview, I wrote them a
letter declining a second interview and provided them an extract from the
C Standard where it says memmove must work properly even when its operands
overlap.

In many implementations , memcpy (dst, dst + n, count) will behave
exactly like memmove (dst, dst + n, count) if n 0, while memcpy (dst
+ n, dst, count) will usually invoke some rather bizarre behaviour.
That doesn't change the fact that it is undefined behavior, and
relying on this is of course utterly stupid.

For example, a highly optimised version of memcpy intended for a
processor with vector registers could look like this:

size_t i;

if (size % 16 != 0)
{
size_t originalsize = size;
size_t i;
size -= size % 16;
for (i = size; i < originalsize; ++i) dst [i] = src [i];
}

for (i = 0; i < size; i += 16)
"Copy 16 bytes from src + i to dst + i";

[Richard Heathfield]

Re: what is the output of this program?

Joachim Schmitz said:

Richard Heathfield wrote:

<snip>

>In fact, there's nothing
>"old-style" about the function definition. The problem lies with the
>return type, and void main isn't old-style - it's simply *wrong*.

The empty parens are old style, vs. main(void).

If that's truly what the message means, it's silly - the compiler is
ignoring a genuine error and instead flagging up perfectly harmless code.

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Eric Sosman]

Re: what is the output of this program?

Richard Heathfield wrote:

Joachim Schmitz said:
>

>Richard Heathfield wrote:

>
<snip>
>

>>In fact, there's nothing
>>"old-style" about the function definition. The problem lies with the
>>return type, and void main isn't old-style - it's simply *wrong*.

>The empty parens are old style, vs. main(void).

>
If that's truly what the message means, it's silly - the compiler is
ignoring a genuine error and instead flagging up perfectly harmless code.

I wouldn't call it a "genuine error" to use an implementation-
defined extension.

5.1.2.2.1 Program startup
[...] main [...] shall be defined with a return type
of int [...] or in some other implementation-defined
manner.

It's not portable, and the next debutante in the Compiler's
Coming-Out Cotillion is not obliged to dance this particular
dance well or at all, but it's no contravention of C's rules.

--
Eric Sosman
esosman@ieee-dot-org.invalid

[Richard Heathfield]

Re: what is the output of this program?

Eric Sosman said:

Richard Heathfield wrote:

>Joachim Schmitz said:
>>

>>Richard Heathfield wrote:

>>
><snip>
>>

>>>In fact, there's nothing
>>>"old-style" about the function definition. The problem lies with the
>>>return type, and void main isn't old-style - it's simply *wrong*.
>>The empty parens are old style, vs. main(void).

>>
>If that's truly what the message means, it's silly - the compiler is
>ignoring a genuine error and instead flagging up perfectly harmless
>code.

>
I wouldn't call it a "genuine error" to use an implementation-
defined extension.

It's only implementation-defined if it's documented. Is it?

<snip>

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999