[nycbug-talk] MSNBC on the decline of technology jobs

[alex at pilosoft.com]

On Wed, 22 Jun 2005, Marc Spitzer wrote:

> > If you want me to give examples in software development, my favorite
> > interview question is "c=0; c=c++;" what is the value of c?  The right
> > answer is 'undefined', it can be 0, 1, or 500. Now, its all about how
> 
> actually I would say 1, compilers may differ but according to what I
> remember of C, been years, it should be 1.  Here is why:
> 
> 1: c=0
> 2: c=c ( c=0)
> 3 : c++ ( c = 0 + 1)
> 
> that is how it should work, gcc 3.3.3 agrees with me.  The 500 thing
> is not plausable, 0 and  1 are though.
Incorrect. When I ask questions and say what is the right answer, I take 
the time to research, so please do the same if you are trying to prove me 
wrong ;)

See, you are confused. You are trying to look what the compiler would do. 
Instead of looking what the *language definition says*. To answer this 
question, you need to be a "language lawyer" - interpreting the standard. 
Now, C standard says that for certain things, the behavior must be:

* 'implementation-defined' - meaning that on a given platform, same input 
should produce same output, and this should be documented (i.e. in this 
case, code would produce consistently 1 or 0).

* 'unspecified' - compiler can do whatever it sees fit as far as ordering 
(in this case, compiler could produce code that would output 1 or 0 
depending on the compile options, or even at runtime)

* 'undefined' - compiler can do whatever it wants, including code that 
crashes your computer and formats your hard drive. The code is incorrect.

Now, the key concept here (which if mentioned at interview would get 100% 
credit) is a 'sequence point'.  See this:

http://publications.gbdirect.co.uk/c_book/chapter8/sequence_points.html
http://www.embedded.com/shared/printableArticle.jhtml?articleID=9900661

In this case, this is "variable read and written without intervening 
sequence point". 

In this case, standard says it is "undefined" - meaning platform has
absolutely no requirements as far as what it should (or shouldn't) do.
Technically, that code can crash, and compiler would still be correct
doing it. More precisely,

> 
> here is a more fun one:
> c=0; c =+ ++c;
> 
> here I would vote for 2, gcc says 1
> 1: c=0
> 2: ++c ( c= 0+1)
> 3 c= c+c (c = 1+1)
Doesn't matter what you vote for, matters what ARM says it is.

> > someone thinks about resolving this: Break the statement into
> > operations, and try to figure whether assignment or post-increment
> > will happen first.
> 
> by definition post incrament happens after assignment, again compilers
> may vary but that is how it should work
Whoever told you that was wrong. Increment does not happen after 
assignment. Increment and assignment are guaranteed to complete before 
next statement is evaluated, that's all.

> > the code is going to be *compiled* to, etc.
> > 
> > C has a lot of "gotchas" - if you don't know them and can't recognize
> > them, you'll fail my interview. I like to give examples that'd make a
> > difference between signed int/unsigned int, proper casting, why you
> > shouldn't use strcpy, why you shouldn't cast a pointer into an int.
> > (Note: just merely knowing that you *shouldnt* doesn't give you any
> > points on this test, you need to know why). Those questions I consider
> 
> cast a pointer into an int bad for 2 reasons:
> 1: size mismatch, shoe horn 64 bits into 32 bad
Yes

> 2: the null pointer is not gaurenteed to be 0, if I remember my triva
> correctly dec alpha chips used an address that could not be addressed by
> the hardware as the null address of the pointer in question and it did
> not equal 0.  I may be wrong on this could have been mainframes.  I do
> think they did a compiler hack to map the NULL to 0 but it was only 1
> way.
Yes.

> Is the correct answer "I really hate answering these stupid questions?"?
Nah. It is to come up with most flattering answer. ;) Lots of sites on teh
intarweb have this stuff, so I don't want to repeat myself