
Deep C - FrancescoRizzi
http://www.slideshare.net/olvemaudal/deep-c
======
Maro
While knowing the standards makes you a better programmer, it's still bad
programming practice to write non-excplicit, cryptic code.

I think the boy's initial "I would never write code like this" response is
spot on. I also agree with the boy's implied annoyance and "who cares what
this badly written program actually does" stance.

These are fairly terrible interview questions. They test knowledge of
standards and various obscure behaviour, but it's far more important what kind
of code (readable, explicit, maintainable, simple, architected, commented,
performant, bug-free, etc.) the person writes. In real life, the boy may
actually be a better programmer than the girl. It's just not a good,
comprehensive test.

Nevertheless the examples are fun, but I would never ask them in an interview.
Interview time is precious and not to be wasted on stuff like this, unless
you're interviewing for a compiler job...

EDIT: Most of the above applies to the first, C part of the interview. In the
second, C++ part, the stuff the girl says is mostly basic knowledge that is
useful on a daily basis.

~~~
pwaring
I agree on the "I would never write code like this" point. I have never read
the C standard and don't know off the top of my head what happens when you
fail to initialise a static vs auto variable, but I don't really care because
I would never write code which relies on whatever the implicit behaviour is.
If I found code which did that on a project I'm involved with, I'd search for
what is supposed to happen and then fix the code to make it explicit.

If I was interviewing, I'd much rather hire someone who said "I'd never write
code like that" to someone who reels off what might happen in every possible
scenario, unless I was hiring for a compiler writer.

~~~
mquander
I disagree. I feel that knowing what might happen demonstrates that the
individual has considered the design of C carefully and taken the time to find
out how it is, and why it is the way it is. I think that sort of knowledge
always leads to better code in the language.

The man in the example might know to "never write code like" a variable
incrementing and assigning to itself again, but there might be other, more
subtle pitfalls in design and implementation that he succumbs to because he
hasn't given much thought to all the different ways that the rules of the
language can interact.

~~~
philh
I agree - the girl's knowledge might be a net win, provided she doesn't go out
of her way to use it.

Note that it's not all stuff that you can just look up: although you _can_
look it up, it might not be obvious that it needs to be looked up. I had no
idea there was a difference between `int f()` and `int f (void)`, and if that
ever caused problems for me I doubt I would have been able to track it down
easily.

"A gentleman is someone who knows how to play the bagpipes, and doesn't."

~~~
sirclueless
Sure, but would you really care whether someone knew off the top of their head
that %zu is the escape sequence for size_t? Some of the stuff she shows off is
pretty arcane, though pieces of it are actually useful.

Understanding the memory model and execution model is a big plus, because it
lets you write correct and efficient code (and if you are using C you care
about correctness and efficiency). Recalling arcana about the C99 standard is
just overkill and asking someone to pull stuff like that out of a hat in an
interview is asking too much IMO.

~~~
dodedo
I have to work with folks who confuse size_t with int, and as a result they
have overflow bugs depending on whether O_LARGEFILE is in use. So yes, I care.
Not because printf format strings are terribly important, but because
understanding and adhering to the type system is essential to write bug-free
software.

~~~
0x12
If they get overflow errors then your build process does not have the right
warnings enabled/logged.

Suggestion: enable -Wall and treat warnings as errors.

~~~
dodedo
Of course. You and I know they're doing it wrong, however sirclueless
suggested above that type correctness is "arcane" and asks if "we would really
care" when it comes to type issues in printf format strings.

------
wccrawford
While it's tremendously fun to go through and learn, I question whether she
would be a better programmer.

For the first half, the boy is making all the right decisions. He's not taking
changes and using little compiler tricks to do things. He's not being clever.
(For the second half, they appear to deliberately make him stupid. I'm not
sure why.)

She, on the other hand, has a lot more tools in her toolbox. At the very
least, she'll be tempted to use them. And if anyone else is working on the
code, they'd better know those tools as well as she does. That's a dangerous
situation.

Of course, it depends on what they're working on. If they're working with
Carmack on his new 3D engine, she's the obvious choice. He would never keep up
to Carmack.

~~~
temphn
Meta comment: it's funny that a pink haired girl in ponytails is correcting a
boy on hardcore C details. Sure, a few of these women exist in real life. But
we really need to resist these Orwellian psyops as the depiction is not really
reflective of reality.

tl;dr: Nerdy guys don't have much in life. Let them have C.

~~~
wccrawford
Oh, I'm sure it was done on purpose. There's no legit reason it can't be a
girl, but all too often it's a guy. And if they'd put the girl in the 'dumb'
position, the PC people would have jumped up and down on it for furthering a
stereotype.

So I don't mind a bit that they chose the roles as they did.

~~~
Symmetry
To put it more charitably, having a girl as the smart one will do more to
encourage both the typical guy and girl to work hard than the reverse.

------
Cushman
This seems like a false dichotomy to me. The "shallow" character seems
completely uninformed about the basics of computer science, maybe having
worked through a C tutorial or two, while the "deep" character seems to have
an encyclopedic knowledge of every C spec and compiler implementation that's
ever been written. How many interview candidates really fall into one of those
camps?

I don't really know C that well -- certainly nothing spec- or compiler-
specific -- but I got "deep" answers for most of the questions just because I
know that generally C compiles straight to machine instructions, and I know
how computers work. (I got 5/5 on the little quiz, and the tutorial on
sequence points was completely new to me.)

C isn't hard. Thinking like a computer, in any language, is hard. The ability
to predict what code will do, while important, is less crucial than the
ability to figure out what's really going on when you get one wrong. I feel
like calling that ability "deep knowledge" is putting the cart before the
horse.

To put it another way, "I don't know the answer to that question, but here's a
guess" and "I know the answer to that question, here it is" are both less
impressive answers than "I don't know the answer, but give me a second and
I'll figure it out for you."

Or maybe I'm missing the point.

------
zvrba
And here's a link to the PDF:
<http://www.pvv.org/~oma/DeepC_slides_oct2011.pdf>

I hate slideshare requiring registration or facebook login before it allows me
to download it in some decent format.

~~~
bcl
Thanks, the slideshare was starting to go really slow once I hit slide 300.

~~~
mappu
I noticed that too, i'm glad you mentioned it. Q6600 running Chrome 15,
everything was perfectly snappy until somewhere around then.

Maybe slideshare has some sort of architectural problem? Is it seeking through
the slides linearly for every request? Maybe slides after a certain point get
read from disk in multiple segments? Maybe at that exact point in time, the
load on the server increased?

Who knows :(

~~~
pflanze
It's speedy again after reloading the page and typing the slide number to
continue with into the slide number box--at least for a little while.

------
macavity23
I think this slideshow would be better titled 'Standards Compliant C'.

At least for the first printf example, I would employ the boy rather than the
girl. The boy gave a correct answer - what was missing, what would happen. The
girl spouted a bunch of standards that added no value (with the exception of
the 'return 3' which does indeed demonstrate deep knowledge).

In particular, the 'you should add a blank line at the end of your code'
comment would immediately make me suspect her to be a finicky letter-of-the-
law PITA who would be a nightmare to work with.

Standards are all well and good, but if your code compiles with no warnings
and runs without errors according to the spec you were given, nobody of any
consequence is going to give a damn.

~~~
bcl
_"Standards are all well and good, but if your code compiles with no warnings
and runs without errors according to the spec you were given, nobody of any
consequence is going to give a damn."_

Wait, what?! The whole point of this slideshow is that without a deeper
understanding of your language you can end up with errors that you don't
anticipate or understand.

Your code compiles and runs today. But then you rebuild on a different
machine, or with different compiler optimization level, add a seemingly
innocuous piece of code here or there and then it starts acting differently.

Or you deploy it to your customer and they start seeing intermittent problems
with it because you failed to understand when to initialize auto variables.

You can never have too much knowledge about the language (and tools) that you
are using to build your code. I would even go further and say the same thing
about the hardware you or your users are running your code on.

~~~
kenjackson
While I do agree that you can never have too much knowledge, there is a huge
dropoff in value.

 _Your code compiles and runs today. But then you rebuild on a different
machine, or with different compiler optimization level, add a seemingly
innocuous piece of code here or there and then it starts acting differently._

IMO this is the problem with the deck. The "problematic" code is code that ppl
who don't know the corners of C/C++ aren't likely to write. If you're tempting
sequence points in your code, you're asking for trouble, even if you know the
standard well because now you're tempting fate you don't make a mistake and
you're assuming every compiler implements the standard perfectly (and we all
know this isn't the case).

And the smart girl makes at least one potential error. She says that, "You
said that your runtime is 64bit so that means your pointers are probably 8
bytes".

First he never says the runtime is 64bit. He says its a 64bit system running
in 32bit compatibility mode. What does 32bit compatibility mode mean?
Potentially a lot of things. For example, on Windows it means you have 4 byte
pointers. Rather than conjecturing -- this is something she could have just
said, "How long are your pointers?" But her character was one that had to have
an answer -- even if it meant making a potentially wrong assumption.

------
wisty
It's not a commentary on interview questions. It's a tutorial on C language
rules, with a silly little story to make it more interesting.

What _everyone_ is missing is how interesting the tutorial is, despite it
being about a really dreary topic. I'm reading a book called "Why Don't
Students Like School", which goes into some detail about this kind of thing.
It's quite good (and really should be, given that it's about how to make
education interesting).

~~~
gfodor
Here, have an upvote. So many people in this thread are missing the forest for
the trees here and turning this slide deck into a referendum on interview
styles, programming personas, and style. I guess it certainly makes for a nice
bike shed, but the point of this is to help you appreciate some of the finer
details of writing good C code. I like it.

~~~
wisty
That's one of the dangers of "attention grabbers".

"What you learn today Johnny?"

"Pure sodium goes BOOOM!"

"Why's that?"

"Um, the teacher said something about chemistry, but we were all just watching
the fireworks."

------
zwieback
Not sure why there are so many negative comments, the exact detail of the
questions and answers aren't as important as the overall message and the guy
and girl are archetypes.

We're interviewing some candidates for embedded C programming right now and
these are the types of questions (although generally easier) I ask to find out
the level of C expertise. For embedded systems with a focus on stability I
want candidates who have a very good grasp of the fundamentals like the
difference between normal globals, statics, volatile, etc. Also I'd like
people who understand enough about the linker to know about data segments,
zero init and stuff like that. For embedded you generally have to be able to
implement interrupt handlers so the exact translation of a line of C code to
assembly is important, as is knowing what's atomic and what isn't.

I'm continually surprised how many programmers have worked on embedded systems
in C without being able to answer almost any of my questions. Many seem
exactly like the guy in the examples, none like the girl.

~~~
munin
you're not interviewing C programmers, you're interviewing assembly
programmers that use C as a frontend ;)

~~~
zwieback
Yeah, you're probably right, good point.

------
forgotAgain
Unless I asked for more information I would have been turned off by the girl
because she was pedantic. The last thing a team needs is someone who gives a
never ending answer to a simple question. If I prodded for more and she
delivered it and the guy didn't then she wins hands down. Otherwise I want a
simple answer to a simple question and move on to the next thing.

Edit: I only went through the first twenty or so slides. After disagreeing
with the initial premise I didn't think the author earned any more of my time.

------
jrockway
This is important for two reasons:

The first is to remedy the misconception that "C is a really simple language".
It's not.

The second is because while you'll never write any code like this, you'll
probably have to debug code written by someone who did. That means that in
order to use your time efficiently, you need to know what matters and what
doesn't. Writing a regex to replace all "static int foo" with "static int foo
= 0" is going to waste your time and not expose the cause of the bug. If you
didn't know that, your time would be wasted.

~~~
snprbob86
Totally.

I much prefer C over C++ because, at least in comparison, C is a much simpler
language.

However, the motivation for Google's Go is suddenly much clearer...

------
Jun8
The title reminded me of _Expert C Programming: Deep C Secrets_ bu Peter van
der Linden. If you don't have this book buy it today. It's one of the best C
books I've read and AFAIK the only book that combines C and humor! His
description of how to make Oobleck is alone worth the price (for those who are
curious, it's a non-Newtonian fluid, <http://en.wikipedia.org/wiki/Non-
newtonian_fluid#Oobleck>, and also a Dr. Seuss character).

(OK, if you don't want to buy the book, here are the directions:
[http://books.google.com/books?id=4vm2xK3yn34C&pg=PA347&#...</a>)

~~~
andrewcooke
this book is recommended on one of the last slides (although i don't remember
it talking about sequence points, or i forgot, since that was one of the
things i just learnt...; i think they may only have been named in the iso
standard which was probably after that book was published)

and i just found this - <http://publications.gbdirect.co.uk/c_book/> \- which
looks like a good basic intro.

------
ak217
_Would it be useful if most of your colleagues have a deep understanding of
the programming language they are using?_

Not if by "deep understanding" he means "knowing trivia about underspecified
corners of the language that have nothing to do with getting the job done".

~~~
greyfade
No, by "deep understanding," he means "knowing how your code will run on a
given system," which can have a lot to do with "getting the job done,"
especially if your code must be fast and stable.

------
pacala

        static int a;
        ++a;
    

I don't care what the standards say, please just type the initialization value
you need. It's inconsistent to pick a special case, 0, out of 4,294,967,296
possible values, and type something different in the special case.

~~~
barrkel
Initialization of static data is more problematic than you think; it's
particularly susceptible to races.

On the other hand, there are very important pragmatic reasons for using 0 to
initialize data; the OS loader can give you zero pages (corresponding to bss
segment or equivalent) for "free"; free to the point that they don't need to
be stored in the image, and allocated lazily as needed.

~~~
ot
> Initialization of static data is more problematic than you think; it's
> particularly susceptible to races.

Safe initialization of statics is both possible and fast, thanks to an
algorithm by Mike Burrows:

[http://www.open-
std.org/jtc1/sc22/wg21/docs/papers/2008/n266...](http://www.open-
std.org/jtc1/sc22/wg21/docs/papers/2008/n2660.htm)

It is also guaranteed in C++11. GCC has been implementing thread-safe
initialization since version 4, I believe, but I'm not sure whether they use
this algorithm.

~~~
barrkel
That doesn't solve anything relevant; I quote, "the initialization of an
object is indeterminately sequenced with respect to the initialization of an
object defined in a different translation unit"; if you have two pieces of
initialization code in different translation units, each referring to the
other's data-to-be-initialized, you have a race; one is going to get
initialized first (whether the order is determined by the standard, by the
link order, by the arbitration of dragons, it doesn't matter) and the other is
going to be uninitialized when accessed.

I _personally_ think it's better, where possible, to define the relevant types
such that a zeroed structure as a valid state, or else use trivial
initialization (where "trivial" might be defined as literals or constant
expressions). Where this is not possible, explicit initialization (e.g. called
directly or indirectly from main()) ought to be used.

~~~
ot
Wait, I think we are talking about two different things: the spec I pointed to
refers to static _local_ variables, and solves pretty much all the cases I can
think of. (Initialization is delayed until first function call).

You are talking about _global_ static variables, and yes, that's a tricky
matter.

~~~
barrkel
Well, being local doesn't protect you from indirect access; it's the lifetime
that makes statics troublesome, not the scope. The function wrapping the local
may be called by the initialization.

------
haberman
I don't think it's super-important to know eg. what value an uninitialized
static variable will have. If you use it, you should initialize it explicitly,
end of story. If you write code that counts on such detailed minutiae of the
standard, you make your code harder to read for no good reason.

~~~
__david__
I really hate this attitude. Static variable initialization is _not_ "detailed
minutiae of the standard" (nor is operator precedence--I know you didn't
mention that but others in the discussion have). If you don't know those then
_you don't know C_! It doesn't make your code harder to read if you understand
the language. And if you don't understand the language, then _why, oh why_ are
you trying to read or write it?

It's like encouraging people to speak in baby talk because the people
listening shouldn't have to understand all the detailed minutiae of the
English language.

~~~
dekz
Not many people can have an almost complete and thorough understanding on how
each compiler/linker/platform will behave on the various C standards, to
suggest such a thing is silly and to enforce it is borderline insanity.

    
    
      And if you don't understand the language, then why, oh why are you trying to read or write it?

a) To get things done.

b) To attempt to understand the language.

Not everyone can learn the complete work of C standards and quirks just by
reading, some need to read and write it.

------
pwaring
I'm a bit surprised by the suggestion that optimisation somehow makes the
compiler work harder (e.g. catching uninitialised variables), isn't that what
-W flags are for? I'm not sure that optimiser flags will catch anything with
gcc that -Wall and -Wextra would miss.

~~~
silentbicycle
There are warning flags that aren't even usable unless you're compiling with
optimization on, such as -Wuninitialized.

As the gcc man page says, "These warnings are possible only in optimizing
compilation, because they require data flow information that is _computed only
when optimizing_." (emphasis mine)

~~~
pwaring
That only applies to warnings in conjunction with optimisations though, just
turning optimisations on (as shown in the example slide) won't necessarily
pick up uninitialised variables. For example, if I compile the example given
in the slides with -O, -O1, -O2 or -O3 with gcc, I don't get an error/warning,
but I do if I use -Wall.

Also, you can use -Wuninitialized without optimisations and it picks up the
problem, at least in my version of gcc (4.5.2).

~~~
silentbicycle
Indeed, you need the warning _and_ the optimization to make it work.

That note came from the man page for i686-apple-darwin11-llvm-gcc-4.2, FWIW.

~~~
pwaring
Ah, I'm using a newer version of gcc, which seems to catch the warning
regardless of the optimisation level (including none at all). The text of the
man page also seems to be different.

------
snorkel
It's articles such as this that scare developers away from C. You honestly do
not have to mind meld with the C compiler to be a safe and productive C
developer. If you're not sure what's going to happen if you don't initialize a
variable then that's OK, because most developers realize that being explicit
is better than allowing the implicit case to occur in every language.

~~~
hornd
Sure, but I don't think this slideshow was targeted towards the developer who
does not already know C. Instead, it seems to be targeted towards the semi-
experienced C developer who lacks a deep understanding of the standard.
Whether or not that kind of understanding is necessary for everyday coding is
a different topic altogether, but the main point of the article is sound: take
every opportunity to learn.

------
monochromatic
Didn't get very deep into this slide deck, but I did notice that both of those
candidates neglected to complain about using smart-quotes in source code.
Sloppy, wouldn't hire either.

~~~
gfodor
I didn't think it was possible but I think you've out-girled the girl in that
slide deck.

------
kabdib
Some of the stuff /she/ talks about seem to be "how a badly written program
might behave." This is utterly uninteresting.

Q: "What does this buggy program print."

A: (hits first person with a stick)

"Right!"

~~~
rntz
Most code is buggy. Usually its author isn't nearby, and even if they are,
hitting them rarely helps. Knowing the symptoms of buggy code, however, will
help you debug it.

------
polarist
I took something different to many of the comments here. I found the most
important takeaway was hidden in the later part of the slideshow, and referred
to the difference in the attitudes and approaches to learning for two. Clearly
the girl understood that in coding, there's usually a correct way to do
things, and was always in search of that answer.

That correctness has varying levels of importance depending on the
industry/application, but for a sufficiently large and complex project, the
benefits to writing correct code is extremely valuable.

For instance, if it were a team environment and I had to write some
functionality using the code supplied by the girl, I could simply assume
standard conventions and immediately attempt to use her classes in my code. If
written correctly, that code might work without further effort my on end.

If the code were supplied by the guy, I would likely have to go in to the
implementation and ensure that the behavior conformed my expectations. And
having to go through and read the code could require a significant time
investment.

And of course, reading code often takes significantly (10x++) more time than
writing it, so minimizing the necessity for it is essential in maximizing
productivity. I would suspect that in most programming teams that reading
other people's code is what eats up the most time, yet this time can be
significantly reduced by following such a standard.

When the slideshow begins to refer to C++ conventions and the "rule of three,"
the guy shows that he doesn't take into account that others may need to work
with his code. This can be dangerous as this single new team member can
actually cause the total productivity of the team to _decrease_.

While this guy is just a made-up character, I wouldn't be surprised if most
programmers think/act like him. At the very least, the majority of the ones
that I've worked with, do.

On another note, the minutia details of C do come up if you work with and read
enough source code. Being able to understand it is the more important issue at
hand. Also, in response to many comments stating that writing code that works
based on such minutia is poor practice, I think the girl would likely agree.

------
ipsin
I really appreciated the slides, and they have a direct impact on my current
C++ side project. I breezed through the bits that were not about C or C++, but
here's what I took away:

1) Add "-Wall -Wextra -Weffc++" and fix the problems found 2) Have some
insights into the various C/C99/C++ language contracts, including what
sequence points are, how data is packed, and how expressions are evaluated. 3)
Learn when to use delete or delete[], when to declare a destructor virtual.

If anything in this summary piques your interest, you may want to check out
the full presentation.

------
andrewcooke
this is great, but also embarrassing. not only am i a worse c programmer than
i thought (i thought i was pretty good), but i burnt lunch because i forgot
what was on the stove while reading it :o)

------
grout
C is an incredibly sharp industrial-strength tool. There is absolutely nothing
about C that can't trip you up and break your program if you don't know it by
heart. But if you _do_ know it by heart, forwards and backwards, it has no
equal.

Or, if you prefer: It is a crazy girlfriend: serving your whim one second,
burning your clothes the next. Pay it close attention or be ready to buy a new
wardrobe regularly.

~~~
grout
And as for coddling people who can't be bothered to know the language: Fark
'em. Use the whole language; that's what it's there for.

------
mace
This is brilliant. It contains simple and direct explanations of C's (and
C-based languages) rough edges that many programmers encountered or been
bitten by but few have taken the time and effort understand.

I appreciate the presentation style too. The characters clearly represent the
difference between deep understanding and casual knowledge of the subject.
Good stuff.

------
akmiller
These slides makes it look like you have to be one type or the other. I'd
suggest that the boy is an excellent candidate for the job and that you could
help provide him the lower level understanding that you would like your
programmers to have.

The key to me is how the candidates gain the understanding of whatever
languages they use. Meaning, is programming something that they really enjoy
and are learning on their own time and solving some of their own problems. Or,
are they simply picking up programming to try to get a better paying career
(aka the types of people that are often drawn to those 6 week learn to program
type of schools). Therefore, for me and the interviews I have done in the past
asking candidates about books they've read or programs they've worked on (for
themselves or others outside of their employment) are often times much more
enlightening.

------
robot
Ironically, the examples provided for illustrating your 'deep C' knowledge,
are in fact superficial.

I don't really care if <stdio.h> has a printf definition, or whether C99
behaves differently. You might care more if you are an app programmer.

What I care about is the universal properties of the language that applies
everywhere. Also that's where the strength of C comes out. For example, what
is a function? What does it compile into? Why are there arguments, return
values? How do they get represented? These are far more important questions
than how C99 dictates entering the program from int main(). That's least of my
worries. Programs I write usually enter a C program from _start

------
oscardelben
I really enjoy this presentation. If you want to learn C programming from
scratch I also recommend to study Zed's book "Learn C the hard way".

<http://c.learncodethehardway.org/book/>

------
tjpp
Someone mentioned Expert C Programming: Deep C Secrets as a good book to learn
the C standards. Are there any other books that or resources one would
recommend to learn this sort of material?

~~~
andrewcooke
no, it's not a good book to learn the standards! :o) for that you are better
with harbison & steele or similar (although that's more a reference - maybe
this <http://publications.gbdirect.co.uk/c_book/> which i just found?). deeper
c is more like a collection of essays that explore interesting corners - it
doesn't attempt to cover everything (i enjoyed it, i'm just saying it's not
what you described...)

ps you say standards (plural) - all the above is c only.

~~~
pyre
Though C99 and C89 could be described as different revisions of the same
standard, they could also be thought of as separate standards too.

------
botj
Thanks! I needed a reminder why I hate C so much.

You must be a language lawyer in order to do anything moderately complex and
then be met with "the standard doesn't say anything about that!" when you
realized the standard library doesn't include the most basic of things (yeah
comp.lang.c, I'm looking at you...).

Yeah, I know. C++0x will be the grand unifying standard to rule them
all...sure.

------
burgerbrain
Is this articles note about needing to place a newline at the end of a
standards compliant C program actually accurate?

When I write out a file containing "aaaaa" with nano (to avoid any unusual
tricks vim might use), and then hexdump it, I get "6161 6161 0a61". In other
words, nano slapped on an ending newline when I saved. It is my impression
that everything does this.

~~~
sirclueless
It has long been unix convention that every line of text is followed by a
terminating character. It used to be that many command-line tools relied on
this, I suspect most tools are more forgiving nowadays. Nearly all linux/unix
text editors perform little normalizations to be as compatible as possible. I
bet if you opened a file in vim's binary editing mode (vim -b) you could write
it without the final line ending (does nano also have a binary mode? might be
worth trying).

Edit: Apparently nano has a -L option that skips the last-line normalization.

~~~
greyfade
If you open it in Emacs, by default (at least it did when I toyed with 21) it
leaves the trailing newline off.

------
sehugg
"Well, whatever. Lousy compilers." I feel ya bro.

------
toksaitov
I recommend students to take OS development course at university. Many
concepts of C are discussed and viewed in practice in this class: the relation
of the static storage class in C and the .bss section of the object/executable
file, the stack and calling conventions of different processor architectures,
and so on.

------
dblock
Let me brag first: I could be that girl in the interview. Yay me. But am I the
only one to think these are obsolete skills? Isn't there more to software than
knowing C++ at this level? Would I want to spend 10 years on learning it as
well as I know it now, today in 2011?

~~~
spc476
Don't be so sure. I'm currently writing C code that has run on Linux (Intel,
both 32 and 64 bit systems), Solaris (Intel 64 bit, 32 adn 64 bit SPARC) and
Mac OS-x (not sure, since we don't actually deply on Macs, but we have several
developers that use them), and most of this code deals with binary files and
some custom network protocols, so alignment issues are important.

It was also neat to see my code run flawlessly under Valgrind (we were
attempting to debug an issue with the 32 bit Intel Solaris build---it may be a
compiler issue since that's the only platform (out of the ones listed above)
the code broke on, but I haven't investigated the issue enough to say for
sure).

------
cefarix
This is the most mind-tickling thing I have seen/read/watched in a long while!
I am going through all the slides and now I know how to interview other
coders. Thanks for sharing this!

------
Ideka
Slide 231:

Q: _So why doesn't the compiler reorder the members in the structure to
optimize memory usage, and execution speed?_

A: _Some languages actually do that, but C and C++ don't._

And that's because...?

~~~
gilgad13
In C, at least, it helps to think of regions of memory independently of any
meaning overlaid on top. For instance, there is plenty of code that depends on
behavior like this:

    
    
        struct list_node {
            struct list_node * next;
            struct list_node * prev;
        }
        
        struct useful {
            /* This struct should be part of a list, so include the list header first */
            struct list_node;
        
            /* That data that this struct is storing follows */
            in_addr_t sip;
            in_port_t sport;
            in_addr_t dip;
            in_addr_t dport;
        
        }
    

Then, you can write a generic list walker by casting the a "struct useful * "
to a "struct list_node * " since the first fields will match up.

This is just one example, another would be parsing and unwrapping ip headers
and data sections. As I'm sure you've noticed, C prefers explicit to implicit,
and this applies to the layout of memory as well.

 _edit:_ example: [http://stackoverflow.com/questions/3766229/casting-one-
struc...](http://stackoverflow.com/questions/3766229/casting-one-struct-
pointer-to-other-c)

~~~
cperciva
The first named element of a structure is required to be located at the same
address as the structure, yes; but I'm not aware of any requirement beyond
that.

Can you point me at the relevant paragraph?

~~~
kristoffer
Elements are required to be "sequentially allocated":

This is from the draft N1256 document as I don't have access to the official
standard. From 6.2.5 - Types:

"A structure type describes a sequentially allocated nonempty set of member
objects (and, in certain circumstances, an incomplete array), each of which
has an optionally specified name and possibly distinct type"

I can say that a lot of device drivers in the Linux kernel depend on this ...

~~~
cperciva
Hmm, I understood "sequentially allocated" to mean "this structure gets a
block of memory and no other variables will be allocated space within that
block". Your interpretation would make sense, though.

As for Linux device drivers... it wouldn't be the first time that the Linux
kernel (and especially device drivers) assumed a certain compiler behaviour
which wasn't guaranteed, with hilarious results on later compilers.

------
sktrdie
I love how a simple slideshow made out of cartoon characters got me knowing
about the C and C++ standards more than a written reference ever did.

------
0x12
Long time C coder here. Knowing this stuff just shows you've had more
interaction with your C compiler(s) than with humans, which is fine (I knew
quite a few of the details except for some of the C++ differences because,
well, I code C, not C++).

That said, _relying_ on obscure stuff is where the problem lies. Long time C
hackers almost always agree on one thing (if maintainable code is their goal
and they're not engaging in some silly contest on how to squeeze a certain
program into a ridiculous number of bytes or on how to write a program that
you can't understand on purpuse): If you want your code to be maintainable in
the long run try to be as transparent as possible about what the code does,
don't rely on obscure or implementation dependent features.

So the 'girl' probably has huge experience, but the 'boy's answer is equally
valid from a novice's point of view, because it (probably) gets the job done
with a minimum of fuss (at least wrt to the initial set of questions). At some
point he'll have to expand his knowledge.

If you had to sit through an exposition like that for every silly simple
question the days wouldn't be long enough to get any work done. Literal
answers like the girl gives are rarely productive, but it is good to have the
knowledge that allows you to give those answers. It isn't a must for every
position though, and even 'lesser' programmers have to learn somewhere (but
when you're hiring you want to hire the best you can at the right price).

Oh, and please, do initialize your local variables before first use ;) Even if
you are compiling with the debug options on, not initializing your locals
before first use is a really bad idea, no matter how much you know about your
compiler.

Later on in the series the differences get more interesting, keep clicking :)

What is probably frightening off many people from C is that there is a lot of
arcane knowledge that the 'girl' is exposing that can actually be helpful
during the debugging stage of writing a program, and that there isn't really a
manual that you can read that will tell you all that stuff.

The only way that I know to come by it is to write code for many years and to
run into those issues. I've had a couple of all-night debugging sessions that
are still pretty vivid after many years and it is interesting that those bugs
taught me lots about how compilers optimize, possibly more than I learned from
reading books on the subject.

C bugs can be pretty subtle. The 'girls' knowledge can be helpful while doing
hardcore stuff.

Given the choice between the two candidates I'd probably pick the girl
(assuming she wants the same salary, which is very unlikely) and put a daily
time limit on exposition ;), the 'boy' simply doesn't have that much
experience yet.

Oh, and you can declare your 'main' fuction to be int main(void) all you want,
argc and argv and envp will still be passed to it.

Keeping your globals 'static' in the file they are declared in (instead of
(gasp!) having a bunch of globals that are declared 'extern', try to avoid
that if you can) is good practice.

And so on. In short, there is a lot to know about any programming language,
you can use questions like these to gage experience levels, don't rely on
obscure stuff, explicit is better than implicit, don't expose more than you
have to and so on.

------
DannoHung
Why does C allow so much bullshit to work?

~~~
suivix
It doesn't matter, because in the professional world people don't use tricks
in their code; rather, they keep it simple and understandable for the next
person to come along. For example where I work it's common in code reviews to
see comments like "that's confusing, put more parenthesis there", etc.

------
testz3453
Slides don't work in Opera web browser after 54 page. In Chrome they work.

~~~
TheoLib
Worked fine for me in Opera under Windows XP, although I got bored with the
presentation by the time I got into the 120's pages and quit.

------
bandushrew
That was a brilliant read, thanks.

where can I find more discussions like that?

------
loup-vaillant
1) The girl sounds so much like Hermione that I don't want to be her.

2) I hate C++.

3) Oh, crap, I already knew 98,5% of all this (thanks to the C++ FQA in part,
but still). I guess I'm a language lawyer now…

~~~
norswap
Found myself thoroughly annoyed by the style of the girl answers too.

Making the reader feel dumb makes for a terrible presentation choice.

------
billpg
Takes me back to my days reading comp.lang.c.

