Hacker News Reader

>I think this was silly, the author clearly does know C but they are complaining about optimizing compilers which do things "behind your back" and are becoming an increasing nuisance

I think the compiler behaviour is meant to be illustrative of the main point, not the main point itself, which I think is simply that the actual C language is more complicated than people appreciate. Most of the examples have nothing to do with optimization whatsoever; they're purely focused on correctness.

The article has nothing to do with optimizing compilers, nor requires knowledge of them. It merely uses optimizing compilers to illustrate what is and what isn't legal C. When there's undefined behaviour, the compiler has almost free reign, so it's important for a C developer to know what is and what isn't undefined behaviour.

My boss who is a C developer had only two answers wrong, he didn't remember you could tentatively declare a global var, and he was fooled by the comma operator inside the array index.

On the topic of (overly) aggressively optimising compilers:

http://blog.metaobject.com/2014/04/cc-osmartass.html

...and attempts at turning C into something a bit less programmer-hostile:

https://news.ycombinator.com/item?id=8233484

My point of view is that compilers should be optimising at the level of machine instructions, not by attempting to second-guess the programmer and remove code that it thinks invokes UB. I've looked at tons of compiler output over the years, and there's plenty of opportunity for optimisation in instruction selection and register allocation... C should be a "do what I say, not what I mean" type of language.

Meh, the problem is the preprocessor. A lot of really silly things are produced by macro expansion, so the "obviously silly" optimizations really do end up mattering.

That sounds interesting, but I'm suspicious. Do you have any examples of such macros and maybe some statistics or ideas how often they are actually seen in the wild?

There are also libraries such as libCello[0] and Viola[1] (mine) to really simplify C through macros. libCello is some really cool stuff.

[0] http://libcello.org/ [1] https://github.com/eatonphil/viola

I have a set of incomplete notes headed "typesafe object orientated macro assembler?" which is my thinking on this question. I think that captures what people want: optimal direction of the machine, with all modern conveniences and automated error prevention.

> they are complaining about optimizing compilers which do things "behind your back" and are becoming an increasing nuisance.

Actually no. I think there was maybe one case where you could argue it was the optimizer that is producing different results than you'd expect for unoptimized output, but in most cases you have a problem that exists because of poor assumptions on the part of programmers/error prone language definitions.

That's only the one example, and the author could have thrown his hands up with the usual explanation that undefined behaviour entitles the compiler to launch missiles at you or whatever.

But in fact it's quite a reasonable (the only reasonable?) approach to optimisation, given a function that might invoke undefined behaviour on certain arguments, to emit code that is optimised for work on arguments that don't.

That doesn't seem to me to be tortured logic. The compiler ought to make that optimisation, always. It might be perfectly clear to the programmer that the function in question can never be sent a null pointer, but only by reasoning about the program on a level the compiler can't. It's only a minor side benefit that this can allow a certain amount of reasoning about the code paths that might be taken when you DO invoke undefined behaviour. That usually won't be much use, but might help one identify the kind of error one has made.

I expect most of us here have puzzled over some confusing output from a C program and tried to work out, from the output, whether we made an allocation error or overflowed a buffer or were off-by-one on some bounds. It's a wonderful language in some ways, but the pitfalls are there. Which is the point the author is trying to make.

>But sheesh, sometimes I think these are C programmers who don't have the guts to become Rust programmers.

I suppose another perspective is that there are no shortage of programmers who are suffering from the Stockholm Syndrome, and having them make excuses for existing language's shortcomings are one reason it is harder to get critical mass behind less borked languages ;-)

In a similar vein to the original article, some may like to play along with: http://www.gowrikumar.com/c/index.php

...anyway, I don't see the problem exposing people to potential pitfalls. It's almost like people arguing that people shouldn't read "Expert C Programming: Deep C Secrets":

https://www.google.com/search?q=expert+c+programming+deep+c+...

...also I'll just throw this out here:

http://blog.llvm.org/2011/05/what-every-c-programmer-should-...