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

81–90 of 120 posts

Re: Undefined Behavior in 2017

#81

Post by staticassertion »

jasode wrote: post #58
MichaelBurge wrote: post #53

Earlier quoted context omitted.

If somebody asks you what "cat" does, do you say "It copies its input to its output, unless there's a bug in cat or the C compiler that compiled it or cosmic rays hit the program on disk"?

>If somebody asks you what "cat" does, Yes I get what you're saying but I'll try to emphasize again that I'm not trying to play semantic games to irritate everyone. (Yes, we can play word games such as "a tank is an armored military vehicle -- unless it is just a cardboard facade to fool Germans that the Allies are invading a different a part of France's coastline or acting as a movie prop for special effects work.")…

I agree. This comes up a lot when discussion C/C++ - is it the compiler's fault, the developers, etc? The reality is it's irrelevant. Rust-the-language is safe but no one uses rust-the-language they use rustc. The end result is that it is possible to have memory unsafe rust code without unsafe blocks.

Rust developers should be aware of this - they're almost always incredibly trivial patterns to avoid, but only if you know about them.

Re: Undefined Behavior in 2017

#82

Post by kazagistar »

iainmerrick wrote: post #79
adrianN wrote: post #61

Earlier quoted context omitted.

But the optimizer doesn't give up in this case. It successfully figures out that the loop has no side effect except heating up your processor and eliminates it.

What's the advantage of eliminating the loop? If the compiler is able to do that analysis, why not flag the endless spin loop as a compilation error?

Loop is inside a function, that can have no side effect conditionally.

Function is used in multiple places and inlined.

With inlined context, compiler can eliminate loop sometimes.

Re: Undefined Behavior in 2017

#83

Post by sp332 »

sullyj3 wrote: post #68
wamaral wrote: post #64

Earlier quoted context omitted.

Then by all means reject it, way better than blowing up in production.

I can't tell if this is satirical, but to be clear, you're proposing to disallow addition?

You could test whether overflow is going to happen first. Or use a math library that explicitly overflows with predictable results.

Re: Undefined Behavior in 2017

#84

Post by VHRanger »

nenreme wrote: post #44
chrisdew wrote: post #2

How many of these 200+ undefined behaviours exist in more modern low-level languages, such as Rust and D?

D is memory unsafe by default so it probably has a lot of them.

D runs in @system by default but there are @safe which enforces safety and @trusted (like unsafe in Rust). Those are all attributes you can write libraries in like @nogc etc.

Re: Undefined Behavior in 2017

#85

Post by unrealhoang »

lorenzhs wrote: post #74
unrealhoang wrote: post #70

Earlier quoted context omitted.

Or RAII, a la Rust

"RAII is associated most prominently with C++ where it originated" ( https://en.wikipedia.org/wiki/RAII )

But Rust is where it's taken to the extreme (use on memory resource), and used to prevent a class of UBs (use-after-free, double-free, dangling pointer...)

Re: Undefined Behavior in 2017

#86

Post by [deleted] »

kazagistar wrote: post #82
iainmerrick wrote: post #79

Earlier quoted context omitted.

What's the advantage of eliminating the loop? If the compiler is able to do that analysis, why not flag the endless spin loop as a compilation error?

Loop is inside a function, that can have no side effect conditionally. Function is used in multiple places and inlined. With inlined context, compiler can eliminate loop sometimes.

[deleted]

Re: Undefined Behavior in 2017

#87

Post by tom_mellior »

steveklabnik wrote: post #66
tom_mellior wrote: post #33

Earlier quoted context omitted.

> Note that all of these are inside of unsafe blocks. Besides unsafe blocks, Rust has no undefined behavior, and the compiler will prevent you from doing any of these things. It's true that unsafe is needed to get these problems, but they can also occur outside of unsafe blocks. See an example here: https://gankro.github.io/blah/only-in-rust/#unbound-lifetime... Your own code need not use "unsafe" at all, but the pro…

See also https://doc.rust-lang.org/nomicon/working-with-unsafe.html > unsafe does more than pollute a whole function: it pollutes a whole module. Generally, the only bullet-proof way to limit the scope of unsafe code is at the module boundary with privacy.

Not to belabor the point, but...

> the only bullet-proof way to limit the scope of unsafe code is at the module boundary with privacy

I understand how this is meant in the context of that page, and it is true that modules protect against users messing with modules' internal invariants.

But does that also work the other way around? In the example in https://gankro.github.io/blah/only-in-rust/#unbound-lifetime... it's not the caller messing with the callee's state, it's the callee messing up the caller's state. Do modules help at all here? That is, would the function

    fn foo(input: *const u32) -> &'a u32 {
        unsafe {
            return &*input
        }
    }
become less dangerous, or maybe impossible to call, when put into a module?

Re: Undefined Behavior in 2017

#88

Post by burntsushi »

unrealhoang wrote: post #85
lorenzhs wrote: post #74

Earlier quoted context omitted.

"RAII is associated most prominently with C++ where it originated" ( https://en.wikipedia.org/wiki/RAII )

But Rust is where it's taken to the extreme (use on memory resource), and used to prevent a class of UBs (use-after-free, double-free, dangling pointer...)

Not quite. Destructors aren't guaranteed to run, so you can't actually rely on them for memory safety guarantees.

For example, leaking data in Rust is a perfectly safe thing to do. But while destructors help to prevent it, they cannot guarantee that nothing ever leaks. (And some of this depends on what you mean by "leaking" and so on.)

use-after-free, double-free and dangling pointers are all handled by Rust's ownership and borrowing systems.

Re: Undefined Behavior in 2017

#89

Post by ellisonch »

tom_mellior wrote: post #32
jpfr wrote: post #20

I wonder why he mentions this TIS interpreter but not the development of complete semantics for C and specifically the k framework ( https://github.com/kframework/c-semantics ). Afaik, kcc is also really good at finding undefined behavior. Regehr even wrote about it in the past ( https://blog.regehr.org/archives/523 ).

AFAIR from the last presentation on the K framework I attended (a year ago), the publicly available version of their C interpreter is incomplete: It only runs programs that don't need the standard library. That's pretty great for many things! But it's not a turnkey solution for analyzing real applications. For that they had a proprietary commercial version. (Again, this is from memory, and it may have changed.) Anoth…

Original developer of the C semantics in K here! I just wanted to add a pedantic clarification (since pedantry is what semantics is all about).

The semantics of the language itself is more or less complete. On top of that, a sizable portion of the standard library is given semantics directly (e.g, malloc, setjmp, stdargs, I/O including input/output to FILEs, much of printf, etc. are all formalized in the semantics). There's even basic C11 thread support. All of this runs and can be reasoned about formally. I tried to give direct semantics to the things that couldn't be (easily) written in C, because much of the standard library CAN be written in C and so it isn't so critical that it's formalized.

To round out the library you can provide provide C implementations of any missing library functions at compile time (we provide some by default), and it will KCC those just like any other code. The resulting system is pretty good at catching undefined behavior, but it is super slow.

I'm not involved with the commercial version, but they offer a trade off: don't do any semantic checking inside standard library calls in exchange for faster execution times. My understanding is that instead of chugging through the semantics of printf for every bottle of beer on the wall, they just call out to a native of printf. This makes things a lot faster, but it's possible you won't catch as many problems. In general, the commercial version is trying to make using the semantics practical instead of "academically slow", which was all I managed :)

Any questions welcome.

Re: Undefined Behavior in 2017

#90

Post by tom_mellior »

ellisonch wrote: post #89
tom_mellior wrote: post #32

Earlier quoted context omitted.

AFAIR from the last presentation on the K framework I attended (a year ago), the publicly available version of their C interpreter is incomplete: It only runs programs that don't need the standard library. That's pretty great for many things! But it's not a turnkey solution for analyzing real applications. For that they had a proprietary commercial version. (Again, this is from memory, and it may have changed.) Anoth…

Original developer of the C semantics in K here! I just wanted to add a pedantic clarification (since pedantry is what semantics is all about). The semantics of the language itself is more or less complete. On top of that, a sizable portion of the standard library is given semantics directly (e.g, malloc, setjmp, stdargs, I/O including input/output to FILEs, much of printf, etc. are all formalized in the semantics).…

Thanks for the clarification! That's kind of what I remembered, but you explained it much better.
Post reply on HN