(j3.2006) [Fwd: OMG]

[Van Snyder]

You might enjoy this.  I'm glad we don't have (as much of) this as C
has.

https://hackernoon.com/so-you-think-you-know-c-8d4e2cd6f6a6#.umjohumve


So you think you know C?
A lot of programmers claim they know C. Well, it has the most famous
syntax, it has been there for 44 years, and it?s not cluttered with
obscure features. It?s easy!

I mean, it?s easy to claim that you know C. You probably learned it in
college or on the go, you probably had some experience with it, you
probably think that you know it through and through, because there?s not
much to know. Well, there is. C is not that simple.

If you think it is???take this test. It only has 5 questions. Every
question is basically the same: what the return value would be? And each
question has a choice of four answers, of which one and only one is
right.



1

struct S{
  int i;
  char c;
} s;

main(){
  return sizeof(*(&s));
}

        A. 4
        B. 5
        C. 8
        D. I don?t know.

2

main(){
  char a = 0;
  short int b = 0;
  return sizeof(b) == sizeof(a+b);
}

        A. 0
        B. 1
        C. 2
        D. I don?t know.

3

main(){
  char a = ? ? * 13;
  return a;
}

        A. 416
        B. 160
        C. -96
        D. I don?t know

4.

main()
{
  int i = 16;
  return (((((i >= i) << i) >> i) <= i));
}

        A. 0
        B. 1
        C. 16
        D. I don?t know.

5.

main(){
  int i = 0;
  return i++ + ++i;
}

        A. 1
        B. 2
        C. 3
        D. I don?t know.


That?s it, put down your pens. The answers are just after the musical
pause.



Great Mass in C minor by Wolfgang Amadeus Mozart [Public domain], via
Wikimedia Commons. That?s right, Mozart also wrote in C.

So, the right answers are:


A B C D
1       v
2       v
3       v
4       v
5       v


Yes, the right answer for every question is ?I don?t know?.

Let?s untangle them one by one now.

First one is actually about structure padding. C compiler knows that
storing unaligned data in RAM may be costly, so it pads your data for
you. If you have 5 bytes of data in a structure, it will probably make
it 8. Or 16. Or 6. Or whatever it wants. There are extensions like GCC
attributes aligned and packed that let you get some control over this
process, but they are non-standard. C itself does not define padding
attributes, so the right answer is: ?I don?t know?.

The second one is about integer promotion. It?s only reasonable that the
type of short int and an expression with the largest integer being short
int would be the same. But the reasonable doesn?t mean right for C.
There is the rule that every integer expression gets promoted to int.
Actually, it?s much more complicated than that. Take a peek in the
standard, you?ll enjoy it.

But even so, we don?t compare types, we compare sizes. And the only
guarantee the standard gives about short int and int sizes is that the
former should not be greater then the latter. They may very well be
equal. So the right answer is: ?I don?t know?.

The third is all about dark corners. Starting from that neither integer
overflows, nor char type sign are defined by the standard. First one is
undefined behavior, the second is implementation specific. But even
more, the size of the char type itself is not specified in bits either.
There were platforms where it was 6 bits (remember trigraphs?), and
there are platforms where all five integer types are 32 bits. Without
all this details specified, every speculation about the result is
invalid, so the answer is: ?I don?t know?.

The fourth looks tricky, but it?s not that hard in retrospective, since
you already know that int size is not directly specified in the
standard. It can easily be 16 bits, then the very first operation will
cause the over-shift and that?s plain undefined behavior. It?s not C
fault, on some platforms it is even undefined in assembly, so the
compiler simply can?t give you valid guarantees without eating up a lot
of performance.

So once again ?I don?t know? is the right answer.

And the last one is classic. Neither order of operand evaluation for +,
nor even the order of precedence between increment operators are
specified, so basically every nontrivial operation that involves i
++ and ++i is a pitfall since they alter their operand. It might work
just like you expect on one platform and might fail easily on the other.
Or not. That?s the problem with unspecified things. When you meet one,
the right answer is always: ?I don?t know?.



Great Mass in C minor by Wolfgang Amadeus Mozart [Public domain], via
Wikimedia Commons

And at this point I only have to apologize. The test is clearly
provocative and may even be a little offensive. I?m sorry, if it causes
any aggravation.

The thing is, I learned C in roughly 1998, and for the whole 15 years
thought that I?m good at it. It was my language of choice in college,
and I?ve done some successful projects in C on my first full-time job,
and even then, when I was mostly working with C++, I thought of it as
over-bloated C.

The pivoting moment came in 2013, when I?ve got myself involved with
some safety critical PLC programming. It was a research project in
nuclear power plant automation, where absolutely no underspecification
was tolerable. I had to learn that, while I did knew a lot about C
programming, absolute majority of what I knew was false. And I had to
learn it the hard way too.

Eventually I had to learn to rely on the standard instead of folklore;
to trust measurements, and not presumptions; to take ?things that simply
work? skeptically,???I had to learn an engineering attitude. This is
what matters the most, not some particular WAT anecdotes.

I only hope this little test would help someone like myself from the
past to learn this attitude in some 15 minutes and not 15 years.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.j3-fortran.org/pipermail/j3/attachments/20170223/643bfd5d/attachment.html