Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Undefined Behavior in 2017

blog.regehr.org

Post reply on HN
Print view View original

41–50 of 120 posts

Re: Undefined Behavior in 2017

#41

Post by caf »

cousin_it wrote: post #34
dom0 wrote: post #16

Earlier quoted context omitted.

The optimizer doesn't work that way. It assumes the code does not do UB and then removes branches that can never be taken if the code executes no UB. That's different from "This is UB, and now I do ...".

I think we deserve a compiler warning whenever a source line of code (not a line generated by the preprocessor) gets removed due to UB exploitation. All such cases are worth the programmer's attention, because they are either useless lines or bugs.

You must also account for the case where the source line removed was only useless because of the specific context it had been inlined to by an earlier stage of the optimiser.

Re: Undefined Behavior in 2017

#42

Post by Jare »

jasode wrote: post #39
justinpombrio wrote: post #4

Earlier quoted context omitted.

In Rust it's pretty limited. Here is the full list, from the Rustonomicron: Dereferencing null or dangling pointers Reading uninitialized memory Breaking the pointer aliasing rules Producing invalid primitive values: dangling/null references a bool that isn't 0 or 1 an undefined enum discriminant a char outside the ranges [0x0, 0xD7FF] and [0xE000, 0x10FFFF] a non-utf8 str Unwinding into another language Causing a da…

>, Rust has no undefined behavior, Correct me if I'm wrong but I don't think such a strong universal statement can be true (even outside unsafe blocks) because LLVM has corner cases of "undefined behavior". (And since Rust is relies on LLVM, ...) Maybe it's more accurate to say that Rust minimizes undefined behavior as a design goal, or it doesn't have intentional undefined behavior.

If safe Rust code does not invoke any of the UB corners of LLVM then Rust can claim to be free from UB. I don't know enough to guarantee or verify it, but it's my current understanding that this is the case.

Re: Undefined Behavior in 2017

#43

Post by maxlybbert »

wereHamster wrote: post #6

Why don't compilers have an option to reject UB with an compiler error? Surely the compiler must know when it comes across a piece of source code whose semantic is undefined.

The argument I've seen is "macros often expand into unintuitive code, especially when multiple macros are involved, so these kinds of warnings would be confusing if there were such macros."

It might be possible to do the same thing if you didn't check any code generated from macros.

Re: Undefined Behavior in 2017

#45

Post by jasode »

Jare wrote: post #42
jasode wrote: post #39

Earlier quoted context omitted.

>, Rust has no undefined behavior, Correct me if I'm wrong but I don't think such a strong universal statement can be true (even outside unsafe blocks) because LLVM has corner cases of "undefined behavior". (And since Rust is relies on LLVM, ...) Maybe it's more accurate to say that Rust minimizes undefined behavior as a design goal, or it doesn't have intentional undefined behavior.

If safe Rust code does not invoke any of the UB corners of LLVM then Rust can claim to be free from UB. I don't know enough to guarantee or verify it, but it's my current understanding that this is the case.

>If safe Rust code does not invoke any of the UB corners of LLVM then Rust can claim to be free from UB.

Sure and I believe that adding a conditional qualification such as "if one does not invoke UB of LLVM" restates my point: one can't make a universal statement that "safe Rust has zero undefined behavior."

E.g., as of this writing, the following "safe Rust" UB issue (3+ years ago) last had comments 21 days ago and I believe it's still open:

https://github.com/rust-lang/rust/issues/10184

Re: Undefined Behavior in 2017

#46

Post by the8472 »

> Loops that Neither Perform I/O nor Terminate

> Summary: This UB is probably not a problem in practice (even if it is moderately displeasing to some of us).

Since LLVM is mostly based around C/C++ semantics this actually turned out to be a problem for rust, because rust can encode diverging functions in its type system and assume certain code sections to be unreachable. If the compiler then optimizes out code and the unreachable (thus not-compiled) section is reached things explode.

https://github.com/rust-lang/rust/issues/28728

Re: Undefined Behavior in 2017

#47

Post by [deleted] »

caf wrote: post #41
cousin_it wrote: post #34

Earlier quoted context omitted.

I think we deserve a compiler warning whenever a source line of code (not a line generated by the preprocessor) gets removed due to UB exploitation. All such cases are worth the programmer's attention, because they are either useless lines or bugs.

You must also account for the case where the source line removed was only useless because of the specific context it had been inlined to by an earlier stage of the optimiser.

[deleted]

Re: Undefined Behavior in 2017

#48

Post by [deleted] »

quantdev wrote: post #37
cousin_it wrote: post #34

Earlier quoted context omitted.

I think we deserve a compiler warning whenever a source line of code (not a line generated by the preprocessor) gets removed due to UB exploitation. All such cases are worth the programmer's attention, because they are either useless lines or bugs.

It's more complicated than this, unfortunately. Imagine an int variable x and two expressions f(x) and g(x) of x. Now imagine an if statement with condition f(x) x is always true. So it's not necessary for the line to be useless or wrong for undefined behavior rules to trigger compiler optimizations.

[deleted]

Re: Undefined Behavior in 2017

#49

Post by ivanbakel »

jasode wrote: post #45
Jare wrote: post #42

Earlier quoted context omitted.

If safe Rust code does not invoke any of the UB corners of LLVM then Rust can claim to be free from UB. I don't know enough to guarantee or verify it, but it's my current understanding that this is the case.

>If safe Rust code does not invoke any of the UB corners of LLVM then Rust can claim to be free from UB. Sure and I believe that adding a conditional qualification such as "if one does not invoke UB of LLVM" restates my point: one can't make a universal statement that "safe Rust has zero undefined behavior." E.g., as of this writing, the following "safe Rust" UB issue (3+ years ago) last had comments 21 days ago and…

>a conditional qualification such as "if one does not invoke UB of LLVM"

A conditional qualification which is intended to be unconditionally true of safe Rust code, outside bugs in the compiler. The universal statement is totally possible, because your conditional is equivalent to saying "if you write valid code".

Re: Undefined Behavior in 2017

#50

Post by caf »

pjmlp wrote: post #29
gpderetta wrote: post #27

Earlier quoted context omitted.

> It is very easy to be efficiently determined at compile time for many cases it is in fact equivalent to the halting problem. What you can do is check at runtime, which has performance implications (from trivial to expensive depending on the check).

Not if the language standard doesn't allow for UB to begin with, then there isn't any halting problem to worry about. This is what the alternatives in the memory safe systems programming language since Algol days do. Surely they still allow for developers to disable some of those checks explicitly , but then it is the programmers fault to choose "performance trumps correctness" instead of "correctness trumps performa…

It doesn't matter if the language defines the behaviour of, say, offsetting an array beyond its declared bounds. That doesn't change the general undecidability of statically proving the offset will always be within the bounds at compile-time - in other words, you need runtime checks in some cases (it's just a matter of whether the compiler or the programmer supplies them).
Post reply on HN