Hacker News Reader

Comment by wyager | Hacker News Reader

>The writer seems to believe that functions on nil pointers crash the program, this is not the case. It's a common pattern in lazy construction to check if the receiving pointer is nil before continuing.

And what happens when you don't check? It crashes. That's the unsafe part.

These crashes are simply not possible in Rust and Haskell, and the type system notifies you if failure is possible (because the function will return an Option/Maybe).

View on HN

Woa, Rust is great, but I think you're going a little far on the hyperbole there.

You can easily generate a segfault in Rust in 'unsafe' (or 'trusted') code; that might only restrict errors of that nature to code that uses unsafe blocks.

Practically speaking that's pretty common; once you enter an FFI unsafe block, you lose all type safety; but you can totally do it without FFI too. Eg. using transmute().

In fact, there's no way to know if you code contains 'hidden' unsafe blocks wrapped in a safe api in some 3rd party library that might cause a mysterious segfault later on.

You can argue that 'if you break the type system you can do anything, obviously'; that's totally true.

I'm just pointing out the statement: "These crashes are simply not possible in Rust and Haskell" <-- Is categorically false.

You can chop your own arms off in Rust just like anything else (including Go).

> You can easily generate a segfault in Rust in 'unsafe' (or 'trusted') code; that might only restrict errors of that nature to code that uses unsafe blocks, but practically speaking that's pretty common; once you enter an FFI unsafe block, you lose all type safety; but you can totally do it without FFI too. Eg. using transmute().

Not directly addressing what you're saying, but, IME people are far too quick to use `unsafe` code. One needs to be quite careful about it as there's a pile of invariants that need to be upheld: http://doc.rust-lang.org/master/rust.html#behavior-considere...

> once you enter an FFI unsafe block, you lose all type safety

You don't lose all type safety, especially not if the FFI bindings you're using are written idiomatically (using the mut/const raw pointers correctly; wrapper structs for each C type, rather than just using *c_void, etc).

Maybe "unsafe" is being used to mean different things, here. Some may interpret it as to refer to unsafe memory access. Others may use it to mean possibility of crashing at run time (due to null pointer dereference).

Null pointer dereference is unsafe memory access.

Not if you just throw something like an exception when the program tries to do it instead of actually accessing that memory location.

that's what mapping an -rwx page at 0x0 does, and as a result it segfaults, which is an access violation.

There is some subtlety about dereferencing a null pointer. Many languages (C, C++, Rust) state that *NULL is undefined behaviour, that is, the compiler can assume that it never happens and optimises based on this. This can lead to a "misoptimised" program that doesn't actually segfault when the source suggests it should.

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

No, you are wrong.

First, mapping that page doesn't cause all null pointer dereferences to segfault.

And second, the language doesn't require a segfault. In fact, it explicitly permits the implementation to do whatever it likes.

That is the difference between safe and unsafe. It is in the language definition.

"the language"... which one? AIUI, Go doesn't state that null dereferences are undefined behaviour, but rather that they are guaranteed to panic.

"The language" ?

C doesn't define behaviour of a null deref, but most compilers map a -rwx page there to ensure that attempts to deref fault.

In what circumstance do they not?

The compilers don't map pages there, the operating system does. The problem is the compiler will optimise assuming that a null deref never happens, so you can have source that looks like it should crash due to a null deref, but the compiler has "misoptimised" it to have very different behaviour.

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

...I'm talking about throwing an exception or something similar, not getting a segfault. Like in Java.

Programs that crash with null pointer dereferences are not very useful.

Considering that "safe" removes most of the usefulness of the word "safe".

Specifically, the word safe, when referring to type systems means "memory safe". Meaning the compiler or runtime either prevents bad memory accesses by construction or ensures dynamic checks are in place that throw an exception or halt execution in case a bad memory access was about to occur. It means the program isn't accessing uninitialized memory and isn't vulnerable to buffer overflows etc. It doesn't mean your program won't ever crash.

I agree it's better to avoid null dereference errors by not putting null in your language, but by the normal meaning of safe here, go is safe.

It does not mean "memory safe" in general. It means different things in different contexts.

Also, I wasn't making a point about the word "safe". I was making a point that if go is "safe", then the word "safe" is useless.

There is a problem here. Don't want to call it "unsafe"? Ok. Call it crashy, instead.

Reply on news.ycombinator.com