Live data from Hacker News

On C-optimizing compilers removing code that has undefined behavior

yodaiken.com

21–30 of 71 posts

Re: On C-optimizing compilers removing code that has undefined behavior

#21
post #12

Earlier quoted context omitted.

While I fully agree with you, but I will still like C to be as self explanatory as possible. C is the closest language for which one doesn't need to know the standard to understand it, at least the standardised C. I think it should be one of the biggest aim of C to let the language as it is(except the standard library). This change creates something that might not be expected by some. If this is replaced by an compil…

> but I will still like C to be as self explanatory as possible. C is not self-explanatory at all and without good knowledge of the standard anyone will write broken code that will fall apart sooner or later. C is not a simple language, nor one with simple semantics. Without knowledge of the standards it is essentially not possible to write portable C code.

"Portable" is a red herring. C used to be a great language for writing non-portable code. That's what the optimization hounds are destroying.

Re: On C-optimizing compilers removing code that has undefined behavior

#22
post #7
post #5

> The programmer has clearly attempted to set x[0]=0 Then why not just write it like that? This is like deliberately shooting yourself in the foot and complaining that your shotgun works.

Exactly. A compiler cannot guess what a programmer intended, but has to stick to the language semantics. Also, the article goes on to argue that uninitialized memory is used to seed random generators, which is generally undefined behavior. I don't think this should be a valid use-case.

That business about uninitialized values being used to seed RNGs threw me for a loop as well.

I think it's safe to say that x ^= x is equivalent to x = 0 and optimize it that way, just like compilers recognize common idioms for e.g. swapping, counting set bits, etc and emit the correct intrinsic instructions.

Re: On C-optimizing compilers removing code that has undefined behavior

#23
School of thought of programmers in the Algol and ML-like family of systems programming languages, "Correctness trumps Performance".

School of thought of programmers in the C language family of systems programming languages, "Performance trumps Correctness".

At least the C++ camp, which has quite a few Algol family refugees, there is some effort to remove few UB from the standard, but not all of them.

In resume, pick your side and don't be surprised for what you get in return.

Re: On C-optimizing compilers removing code that has undefined behavior

#24
post #5

> The programmer has clearly attempted to set x[0]=0 Then why not just write it like that? This is like deliberately shooting yourself in the foot and complaining that your shotgun works.

The problem is that the language allows this code and the compiler accepts it. If the code really does make no sense, then why not disallow it or capture it with a compiler warning? Instead the optimizer is to silently remove the code. Isn't it possible that the programmer knows something that the optimizer is unaware of?

[deleted]

Re: On C-optimizing compilers removing code that has undefined behavior

#25
Undefined behaviour was always there to make possible compilers to optimize as they like (nowadays usually for speed or to ease porting to specific architectures) - that is the essence of C "portable assembly" mentality and it always was. Am I wrong?

I tolally agree that this is a bad mentality for software developement in general, but at least it is the "authentic C way" so I feel that part of the critics ungrounded...

Re: On C-optimizing compilers removing code that has undefined behavior

#26
post #5

> The programmer has clearly attempted to set x[0]=0 Then why not just write it like that? This is like deliberately shooting yourself in the foot and complaining that your shotgun works.

Still, making the compiler do whatever the hell it wants because "hey it's undefined behavior so we have the license to" is just as idiotic. Make the compilation fail and then add a flag to override for those who feel extra smart.

Re: On C-optimizing compilers removing code that has undefined behavior

#28
post #26
post #5

> The programmer has clearly attempted to set x[0]=0 Then why not just write it like that? This is like deliberately shooting yourself in the foot and complaining that your shotgun works.

Still, making the compiler do whatever the hell it wants because "hey it's undefined behavior so we have the license to" is just as idiotic. Make the compilation fail and then add a flag to override for those who feel extra smart.

[deleted]

Re: On C-optimizing compilers removing code that has undefined behavior

#29
post #12

Earlier quoted context omitted.

While I fully agree with you, but I will still like C to be as self explanatory as possible. C is the closest language for which one doesn't need to know the standard to understand it, at least the standardised C. I think it should be one of the biggest aim of C to let the language as it is(except the standard library). This change creates something that might not be expected by some. If this is replaced by an compil…

> but I will still like C to be as self explanatory as possible. C is not self-explanatory at all and without good knowledge of the standard anyone will write broken code that will fall apart sooner or later. C is not a simple language, nor one with simple semantics. Without knowledge of the standards it is essentially not possible to write portable C code.

I was thinking about reading the code line by line. Name any other language in which you can do that, without spending at least a week in that. I don't know what is a simple language according to you, but according to me C seems quite a simple language. Not saying it means that a good quality code is easier to write in C.

Re: On C-optimizing compilers removing code that has undefined behavior

#30
post #11

You don't get to write C and complain about UB breaking your code at the same time.

you do in my opinion, i don't understand why UB is so foundamental to C, in this case woudn't a compiler warnig or error be better?

A lot of UB is runtime behaviour that would be difficult to statically analyse. UBSan (-fsanitize=undefined -fno-sanitize-recover) does a good job of detecting it at runtime.

A bunch of UB is of course static, and often comes with compiler warnings. Some UB doesn't have compiler warnings, but is found by linters and analysers (such as clang static analyzer).

Post reply on HN