4 ms·

The problem is that segfaults are frequently the latter type of problem. You do some unsafe thing and corrupt your state, but keep on going without obvious issu

The problem is that segfaults are frequently the latter type of problem. You do some unsafe thing and corrupt your state, but keep on going without obvious issue. Then at some point in the future, your corrupted state causes an otherwise bug-free portion of you program to segfault.

chubot 7y ago
The problem isn't the segfault -- it's the earlier unsafe behavior. That is, the untrapped error that eventually caused the segfault. If the language only has trapped errors, which are indicated by seg faults, it's a safe language. Every language has such errors. What does divide by zero do? What does blowing the stack / infinite recursion do in Rust? It seg faults. The seg fault is the safe behavior. If the stack overflow overwrote heap data structures or global data structures and the program kept running, that would be unsafe.
- deathanatos 7y ago
  > What does divide by zero do? Returns a value, of course! (And that said, JavaScript does have some trapped errors, such as (1/0).foo.foo (and yes you need the second .foo…)) IMO, the execution "error" here (in this thread) is accessing memory illegally. Sometimes the runtime traps it, but sometimes it does not, and "sometimes" isn't always, so its effectively untrapped as we cannot depend on the trap. (Especially in adversarial circumstances.) And further, the original quote talks about languages — the behavior of a language like C is that memory access is not necessarily trapped; the behavior is not well defined. Given the lack of a requirement in the C language for a trap, I think it is fair to call C "unsafe" given the above definition of safe/unsafe. > What does blowing the stack / infinite recursion do in Rust? It seg faults. Somewhat interestingly, it detects it and SIGABRTs, which technically isn't a segfault. And that's now some black magic that I'm curious about as I really thought it would have segfaulted.
  - banana_smoothie 7y ago
    > such as (1/0).foo.foo (and yes you need the second .foo…) I don't understand the nuance here. In my Firefox developer tools, I can do the following: > (1/0).foo.foo ---> TypeError: (intermediate value).foo is undefined > (1/0).foo ---> undefined > (1/1).foo.foo ---> TypeError: 1.foo is undefined > Infinity.foo.foo ---> TypeError: Infinity.foo is undefined > undefined.foo ---> TypeError: undefined has no properties While these are all different errors, I don't really understand why the '(1/0).foo.foo' case is an example of a _trapped_ error, but the others are not.
    - cyphar 7y ago
      The point they were making is that (1/0).foo is not an error, as it returns a value.
    - chubot 7y ago
      None of those are trapped errors. In Python, Java, C, OCaml, and most other languages, 1 / 0 aborts the program. That is, division by zero is a trapped error. In JavaScript, it's not. It keeps going and lets you do stuff like access nonexistent properties .foo on the result, which are also untrapped errors. So JavaScript is unsafe in Cardelli's terminology. It gives you untrapped errors rather than trapped ones. The program keeps chugging along until you find out later and have to trace backwards to the bug.
      - tome 7y ago
        It's Infinity in Haskell Prelude> 1.0 / 0.0 :: Double Infinity
        WoodTree 7y ago
        Because / is floating point division, and infinity is a defined value in floating point numbers. Try it again with div for integer division.
        chubot 7y ago
        Thanks, removed. I’m sort of surprised by that since my memory is that infinity isn’t a real number, rational, etc. That is, does infinity in Haskell obey some algebraic laws?
  - saagarjha 7y ago
    > Somewhat interestingly, it detects it and SIGABRTs, which technically isn't a segfault. And that's now some black magic that I'm curious about as I really thought it would have segfaulted. It's a signal handler, of course: https://github.com/rust-lang/rust/blob/d8bdb3fdcbd88eb16e1a6669236122c41ed2aed3/src/libstd/sys/unix/stack_overflow.rs#L85 https://github.com/rust-lang/rust/blob/d8bdb3fdcbd88eb16e1a6...
  - Sean1708 7y ago
    > I think it is fair to call C "unsafe" given the above definition of safe/unsafe. I don't think anyone would disagree with this. What they're saying is that a segfault is safe and that's because a segfault is essentially your OS's version of an out-of-bounds error, one of the reasons that C is not safe is because an out-of-bounds access will not necessarily cause a segfault.

chubot 7y ago

The problem isn't the segfault -- it's the earlier unsafe behavior. That is, the untrapped error that eventually caused the segfault. If the language only has trapped errors, which are indicated by seg faults, it's a safe language. Every language has such errors. What does divide by zero do? What does blowing the stack / infinite recursion do in Rust? It seg faults. The seg fault is the safe behavior. If the stack overflow overwrote heap data structures or global data structures and the program kept running, that would be unsafe.

deathanatos 7y ago
> What does divide by zero do? Returns a value, of course! (And that said, JavaScript does have some trapped errors, such as (1/0).foo.foo (and yes you need the second .foo…)) IMO, the execution "error" here (in this thread) is accessing memory illegally. Sometimes the runtime traps it, but sometimes it does not, and "sometimes" isn't always, so its effectively untrapped as we cannot depend on the trap. (Especially in adversarial circumstances.) And further, the original quote talks about languages — the behavior of a language like C is that memory access is not necessarily trapped; the behavior is not well defined. Given the lack of a requirement in the C language for a trap, I think it is fair to call C "unsafe" given the above definition of safe/unsafe. > What does blowing the stack / infinite recursion do in Rust? It seg faults. Somewhat interestingly, it detects it and SIGABRTs, which technically isn't a segfault. And that's now some black magic that I'm curious about as I really thought it would have segfaulted.
- banana_smoothie 7y ago
  > such as (1/0).foo.foo (and yes you need the second .foo…) I don't understand the nuance here. In my Firefox developer tools, I can do the following: > (1/0).foo.foo ---> TypeError: (intermediate value).foo is undefined > (1/0).foo ---> undefined > (1/1).foo.foo ---> TypeError: 1.foo is undefined > Infinity.foo.foo ---> TypeError: Infinity.foo is undefined > undefined.foo ---> TypeError: undefined has no properties While these are all different errors, I don't really understand why the '(1/0).foo.foo' case is an example of a _trapped_ error, but the others are not.
  - cyphar 7y ago
    The point they were making is that (1/0).foo is not an error, as it returns a value.
  - chubot 7y ago
    None of those are trapped errors. In Python, Java, C, OCaml, and most other languages, 1 / 0 aborts the program. That is, division by zero is a trapped error. In JavaScript, it's not. It keeps going and lets you do stuff like access nonexistent properties .foo on the result, which are also untrapped errors. So JavaScript is unsafe in Cardelli's terminology. It gives you untrapped errors rather than trapped ones. The program keeps chugging along until you find out later and have to trace backwards to the bug.
    - tome 7y ago
      It's Infinity in Haskell Prelude> 1.0 / 0.0 :: Double Infinity
      - WoodTree 7y ago
        Because / is floating point division, and infinity is a defined value in floating point numbers. Try it again with div for integer division.
      - chubot 7y ago
        Thanks, removed. I’m sort of surprised by that since my memory is that infinity isn’t a real number, rational, etc. That is, does infinity in Haskell obey some algebraic laws?
- saagarjha 7y ago
  > Somewhat interestingly, it detects it and SIGABRTs, which technically isn't a segfault. And that's now some black magic that I'm curious about as I really thought it would have segfaulted. It's a signal handler, of course: https://github.com/rust-lang/rust/blob/d8bdb3fdcbd88eb16e1a6669236122c41ed2aed3/src/libstd/sys/unix/stack_overflow.rs#L85 https://github.com/rust-lang/rust/blob/d8bdb3fdcbd88eb16e1a6...
- Sean1708 7y ago
  > I think it is fair to call C "unsafe" given the above definition of safe/unsafe. I don't think anyone would disagree with this. What they're saying is that a segfault is safe and that's because a segfault is essentially your OS's version of an out-of-bounds error, one of the reasons that C is not safe is because an out-of-bounds access will not necessarily cause a segfault.