5 ms·

Yes. One flavour of icecream is all we need. (I hope people can see the sarcasm)

nickpsecurity 10y ago
"My qbe C frontend is actually written in myrddin which is a lot like rust/ocaml. To be honest, C is not well suited to places where there is adversarial input such as servers, but when it comes to logical correctness of code I do not see amazing benefits from languages like ocaml." Did you mean two? Or did you come to new conclusions after that experience? Or did I misunderstand that entirely? ;)
- andrewchambers 10y ago
  There ARE benefits to correctness from better languages, just not as amazing as people think. I'm just saying a vulnerability in C is just going to be an out of bounds exception in another language. both cases the code is not correct, one is just safer than the other when it comes to exploits. Keep making more languages, we can't know for sure if we don't try.
  - nickpsecurity 10y ago
    I can see where you're going but I don't think it's correct. There are clearly cases where an error will mess you up whether it goes as far as in C or not. Other times, the language or tooling prevents the error before runtime to ensure correctness. Are you aware of the benefits of Design-by-Contract (Ada/Eiffel), static proving (SPARK), or dependent types (ATS), though? The correctness criteria you can encode in them can straight-up prevent errors at interface or algorithmic expression levels. Three of these have been used for low-level code with two often in real-time and one for an 8-bitter. Depending on automation or interactive use involved, the errors caught at compile-time can increase pretty far past what a basic, low-level, type system can do. So, we already know we can knock out extra classes of errors with such languages. It was proven in theory and in the field. Using or improving them is just good engineering. We can also make more languages in trial-and-error discovery process to see if we find more benefits. Exceeding C's benefits, though, is already empirically proven to be worthwhile whether it's a Myrddin, a SPARK, or an ATS.
  - wolf550e 10y ago
    C code will continue to dereference pointers after object deallocation, access arrays out of bounds, and not complain about integer overflow. Even if input is not an RCE, you will silently get an incorrect result of computation. A safer language helps in cases other than security.
    - majewsky 10y ago
      And there are newer languages that have this problem. I was shocked to see that I could produce a SIGSEGV in Nim within the first 15 lines of code that I wrote.
      - dom96 10y ago
        Why were you shocked? Is it because you're used to languages that prevent null values by default or do you have concerns about the safety of Nim because of this error? Whatever the case, as far as I am aware, sooner or later Nim will prevent nil values by default.
        majewsky 10y ago
        If that happens, I'll gladly look at it again. My point is that we have enough languages with unchecked access to nil values by now.
        jwatte 10y ago
        But how is a nil pointer segv different from a irrefutable pattern mismatch in Haskell, or "undefined is not a function" in JavaScript?
      - SamReidHughes 10y ago
        A segfault on a null pointer isn't a memory safety problem, so that's not the same thing at all.
        nickpsecurity 10y ago
- deleted 10y ago
  [deleted]

"My qbe C frontend is actually written in myrddin which is a lot like rust/ocaml. To be honest, C is not well suited to places where there is adversarial input such as servers, but when it comes to logical correctness of code I do not see amazing benefits from languages like ocaml." Did you mean two? Or did you come to new conclusions after that experience? Or did I misunderstand that entirely? ;)

andrewchambers 10y ago
There ARE benefits to correctness from better languages, just not as amazing as people think. I'm just saying a vulnerability in C is just going to be an out of bounds exception in another language. both cases the code is not correct, one is just safer than the other when it comes to exploits. Keep making more languages, we can't know for sure if we don't try.
- nickpsecurity 10y ago
  I can see where you're going but I don't think it's correct. There are clearly cases where an error will mess you up whether it goes as far as in C or not. Other times, the language or tooling prevents the error before runtime to ensure correctness. Are you aware of the benefits of Design-by-Contract (Ada/Eiffel), static proving (SPARK), or dependent types (ATS), though? The correctness criteria you can encode in them can straight-up prevent errors at interface or algorithmic expression levels. Three of these have been used for low-level code with two often in real-time and one for an 8-bitter. Depending on automation or interactive use involved, the errors caught at compile-time can increase pretty far past what a basic, low-level, type system can do. So, we already know we can knock out extra classes of errors with such languages. It was proven in theory and in the field. Using or improving them is just good engineering. We can also make more languages in trial-and-error discovery process to see if we find more benefits. Exceeding C's benefits, though, is already empirically proven to be worthwhile whether it's a Myrddin, a SPARK, or an ATS.
- wolf550e 10y ago
  C code will continue to dereference pointers after object deallocation, access arrays out of bounds, and not complain about integer overflow. Even if input is not an RCE, you will silently get an incorrect result of computation. A safer language helps in cases other than security.
  - majewsky 10y ago
    And there are newer languages that have this problem. I was shocked to see that I could produce a SIGSEGV in Nim within the first 15 lines of code that I wrote.
    - dom96 10y ago
      Why were you shocked? Is it because you're used to languages that prevent null values by default or do you have concerns about the safety of Nim because of this error? Whatever the case, as far as I am aware, sooner or later Nim will prevent nil values by default.
      - majewsky 10y ago
        If that happens, I'll gladly look at it again. My point is that we have enough languages with unchecked access to nil values by now.
        jwatte 10y ago
        But how is a nil pointer segv different from a irrefutable pattern mismatch in Haskell, or "undefined is not a function" in JavaScript?
    - SamReidHughes 10y ago
      A segfault on a null pointer isn't a memory safety problem, so that's not the same thing at all.
      - nickpsecurity 10y ago
deleted 10y ago
[deleted]