Hacker News Reader

Comment by loup-vaillant | Hacker News Reader

Again someone blaming the victim. I'm kind of sick of this.

While true, your comment doesn't get at the root of the problem. The obvious fact here is that there is a mismatch between the C standard and how the users really use it. The less obvious fact/opinion/fallacy, is that it is not automatically the user's fault.

The standard could be wrong.

Sure, there are reasons why such and such behaviour ended up undefined. Those reason are sometimes weak however: some behaviour ended up undefined on all platforms because some of them couldn't handle it reasonably. The alignment bug here is such an example.

To this day I don't understand why undefined behaviour wasn't specified on a platform-by-platform basis. We already have implementation defined behaviour, after all. I guess this is because it lets compiler writers unify their front-ends and optimizers, but as a result, we cannot use our platforms to their fullest potential.

View on HN

Well, it is blaming someone who does not know how to use its tools. If I had writen a blog post aboug how I spent one day trying to fix a leak and then discovered that I always had to call free() after malloc(); would it still be victim blaming than blame me for not knowing the basic of C?

> The alignment bug here is such an example.

It is not since it allows vectorisation. The error was to assume that what one writes in C translates directly to assembly.

You are missing the point. The standard could be wrong, but it is still the standard. You still have an obligation to conform to it if you are writing C code. It is a prescriptive document, not a descriptive one. It can only be wrong to the extent that it can make poor decisions. Regardless of what it says it is authoritative.

Did I gave the impression we don't need to conform to that standard? That wasn't my intention. I just wanted to point out the standard is sometimes stupid.

Of course we have to conform to the standard, however crazy. The only alternative is forking the language itself.

Undefined behavior is one of the most intelligent things the C designers did when designing the language.

It's a fact of life that not all syntactic forms will have meaning. What's sqrt(-1)? Trick question, There's no meaningful answer (in terms of real numbers alone)! Why should anyone specify if it crashes the program, returns 0, throws an exception, etc.? Who cares? garbage in, garbage out.

Another example, "the floor had a pretty day with his melted spaceship" that is a grammatically well formed sentence but what does it mean? Don't answer that!

> Undefined behavior is one of the most intelligent things the C designers did when designing the language.

I agree, actually. They just went too far. Too many things are undefined for no good reason. Even sqrt(-1) is debatable, by the way: if your platform provides an efficient way to trap, it should probably trap, and the compiler should not assume it will never happen.

And if you want crazy optimizations, consider introducing unsafe assertions into the language. That is, arbitrary boolean expressions the compiler is allowed to assume will always return true.

I don't necessarily disagree that they went too far though I assume they probably had good reason at the time in most cases.

I'd prefer it if the decision to trap or not were an option to the compiler.

It would be nice if there were a GUARANTEE() macro so that the programmer could specify conditions that would never happen even in a production build like: GUARANTEE(n >= 0). Also if trapping was enabled, it would trap at runtime. This is a nice post about that idea http://blog.regehr.org/archives/1096

> The alignment bug here is such an example.

I would even claim that the language on all platforms definitely should be able to specify the "inconvenient" alignments, but that the platforms which can produce the fast code should. If you actually need some suboptimal alignment, you'll need it no matter if the '"language lawyers" cry now. I'd agree, the standard is potentially wrong for not having the possibility. It should be visually obvious that it's not optimal, but it shouldn't be too ugly to use it.

It's better to be able to declare something uniformly than to have pages of #ifdefs or to write a lot of ugly code.

This article and the comments here are good example. The article doesn't end there, it hopefully ends here in the comments, as qb45 claims that there is actually a declarative way for gcc, which at least on one version (the one which he tried) did produce the correct code:

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

But also see the other comments where some question if it realy works across the gcc versions.

> Again someone blaming the victim. I'm kind of sick of this.

C and C++ blame the victim - as do, in practice, compilers for them - by labeling what they've done "undefined behavior" and telling you to do better. I'm kind of sick of C and C++ too. Plenty better than I have attempted to argue the case for optimizers to hold back and behave saner, to stop their abuse. They have failed. I've done plenty of arguing against choosing C or C++ for projects that do not need it. I have failed. I can educate on undefined behavior, that victims may attempt to avoid and combat their abuse. Maybe someday they will break the cycle, and I will have had a hand in enabling them.

While perhaps ogoffart does not perfectly outline that maybe the language is at fault for some UB, ogoffart's links make the case. TIL about yet another source of undefined behavior:

>>> An unmatched ‘ or ” character is encountered on a logical source line during tokenization.

>> With all due respect to the C standard committee, this is just lazy.

My understanding is that this:

  int main() { return !"

Could launch NetHack. Disgusting.

> by labeling what they've done "undefined behavior" and telling you to do better.

If only they did that. But no, they instead label what they've done "undefined behavior", and silently perform optimizations that may or may not break their program entirely. Double emphasis on silently.

There are no victims in engineering. Such phraseology should be saved for disciplines where emotion trumps reason, like politics.

I disagree.

Engineering is full of needlessly awkward tools that end up being misused because of their useless warts. Every time that happens, the engineer that uses it is kind of a victim. And of course, there are the end users, who end up irradiated, spied upon, or robbed because of a technical failure allowed by needlessly unsafe tools.

(Big emphasis on "needlessly". Sometimes, the requirements are so stringent that only the unsafe tools do the job. Embedded environments, AAA games, or video encoders come to mind. Most of the time though, safer, less efficient tools are more than enough.)

Reply on news.ycombinator.com