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

alex at pilosoft.com alex
Wed Jun 22 16:19:54 EDT 2005


On Wed, 22 Jun 2005, Michael Shalayeff wrote:

> Making, drinking tea and reading an opus magnum from Marc Spitzer:
> [Charset ISO-8859-1 unsupported, filtering to ASCII...]
> > On 6/22/05, alex at pilosoft.com <alex at pilosoft.com> wrote:
> > > On Wed, 22 Jun 2005, Francisco Reyes 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:
> 
> -- and ++ when used in an _expression_ along w/ the lvalue itself
> produce undefined _order_ of execution.

> so yes -- 500 is a totally wrong answer. it might be 0 or 1.
Standard disagrees with you. See the difference between 'unspecified'
(which would mean 0 or 1) and 'undefined' (which would mean 0, 1 and any
other value or behaviour) in ARM. Yes, practically you aren't likely to
get anything other than 0 or 1, but, since you want to be pedantic. ;)

http://library.n0i.net/programming/c/cp-iso/intro.html
Paragraph 1.3.12 for definition of 'undefined' and 

http://library.n0i.net/programming/c/cp-iso/expr.html
Paragraph 5.4 for explanation of what is unspecified and what is 
undefined with regard to ordering of operations after sequence point.
> 
> no the post-ops (as well as pre-ops) happen after(before) the lvalue is
> used therefore in case of '=' which is just another operator in an
> expression there is no way to say where the pre/post op is executed.
> 
> > > It shows whether you know what expression is, what rvalue/lvalue is, what
> > > 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
> 
> here is a more fun one:
> char c = 0xf0;
> printf("%x\n", c << 16);
lovely

c is a signed char (strangely enough, compiler lets you assign a value 
that's technically out of range for signed char without a warning)

arithmetic bitwise shift will fill high bits with ones, thus instead of 
0xf00000 you get 0xfff00000






More information about the talk mailing list