Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > what is the output of this program?

Reply
Thread Tools

what is the output of this program?

 
 
Kenny O'Clock
Guest
Posts: n/a
 
      05-28-2008

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\types.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!!!

 
Reply With Quote
 
 
 
 
Walter Roberson
Guest
Posts: n/a
 
      05-28-2008
In article <(E-Mail Removed)>,
Kenny O'Clock <(E-Mail Removed)> 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: }


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
 
Reply With Quote
 
 
 
 
Walter Roberson
Guest
Posts: n/a
 
      05-29-2008
In article <(E-Mail Removed)>,
Pietro Cerutti <gahr_SPAM_gahr_ME_ch> wrote:
>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
 
Reply With Quote
 
dj3vande@csclub.uwaterloo.ca.invalid
Guest
Posts: n/a
 
      05-29-2008
In article <g1l7jg$aln$(E-Mail Removed)>,
Walter Roberson <(E-Mail Removed)-cnrc.gc.ca> wrote:
>In article <(E-Mail Removed)>,
>Pietro Cerutti <gahr_SPAM_gahr_ME_ch> wrote:
>>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
 
Reply With Quote
 
Joachim Schmitz
Guest
Posts: n/a
 
      05-29-2008
Richard Heathfield wrote:
> Walter Roberson said:
>
>> In article <(E-Mail Removed)>,
>> Pietro Cerutti <gahr_SPAM_gahr_ME_ch> wrote:
>>> 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


 
Reply With Quote
 
Dan
Guest
Posts: n/a
 
      05-29-2008

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


I give questions like that just to seperate who is anal and who isn't (and
don't employ the anal ones - they are most likly to take 10 times as long to
write the same page code that no one is ever going to read again).
And just incase you really are dumb, C is not equal to C++.


 
Reply With Quote
 
Richard
Guest
Posts: n/a
 
      05-29-2008
"Dan" <(E-Mail Removed)> writes:

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

>
> I give questions like that just to seperate who is anal and who isn't (and
> don't employ the anal ones - they are most likly to take 10 times as long to
> write the same page code that no one is ever going to read again).
> And just incase you really are dumb, C is not equal to C++.


What do you mean C is not equal to C++ ?
 
Reply With Quote
 
Martin
Guest
Posts: n/a
 
      05-29-2008
On Wed, 28 May 2008 23:52:36 +0100, Kenny O'Clock <(E-Mail Removed)>
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

 
Reply With Quote
 
Joachim Schmitz
Guest
Posts: n/a
 
      05-29-2008
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).


 
Reply With Quote
 
Richard Bos
Guest
Posts: n/a
 
      05-29-2008
"Joachim Schmitz" <(E-Mail Removed)> wrote:

> 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Strange problem - page output contains output from another request Paul ASP .Net 1 04-10-2007 03:41 PM
parse output screen ok but cant get desired output new file! chuck amadi Python 1 06-23-2004 02:16 PM
Sony Precision Cinema Progressive Output vs Component 480p Output Otto Pylot DVD Video 1 04-18-2004 09:49 PM
Is Fuji S3000 3.2m/pixel output, or 6 m/pixel interpolated output? Peter H Digital Photography 43 12-04-2003 02:35 PM
Output / Debug window output bug? John Bentley ASP .Net 0 09-10-2003 07:38 AM



Advertisments