3 ms·

A good compiler might define its behavior. Just because the spec leaves things undefined doesn't mean the compiler should. Arguably a JS VM written in C++ may

A good compiler might define its behavior. Just because the spec leaves things undefined doesn't mean the compiler should. Arguably a JS VM written in C++ may be vulnerable until the compiler is proven not to be.

pcwalton 9y ago
> A good compiler might define its behavior. Just because the spec leaves things undefined doesn't mean the compiler should. All indications are that it's not possible to eliminate undefined behavior from C and C++ without significantly regressing performance. > Arguably a JS VM written in C++ may be vulnerable until the compiler is proven not to be. Vulnerabilities in JS engines are enormously more likely to be the result of undefined behavior in C++ than the result of C++ compiler miscompilations. As I said, eliminating miscompilations in LLVM/clang does nothing to address the problems of C++ UB.
- yorwba 9y ago
  Defining undefined behavior is very different from eliminating it. Every time a compiler compiles code that could potentially invoke UB, it defines what the UB means in that context. If you make the specific way the compiler handles certain cases of UB part of the spec (e.g. overflow wraps around, who cares about sign-magnitude anyway?), then programmers using that compiler can rely on these specifics to write code that does something sensible even when UB is invoked.
  - Ded7xSEoPKYNsDd 9y ago
    The compiled code is also a lot slower. https://www.cis.upenn.edu/acg/softbound/ https://www.cis.upenn.edu/acg/softbound/
    - yorwba 9y ago
      Only if you want to define the undefined behavior to be safe. If you define out-of-bounds writes to lead to memory corruption, your compiled code doesn't get any slower. My point is that you can write your compiler spec to make explicit how exactly various kinds of UB are actually implemented, which then allows you to program to that spec and know that e.g. your overflowing bounds check is not completely eliminated from the program, but instead compiled into the machine instructions you had in mind. If a compiler is verified to conform to such a specification, unintended changes in handling UB will be very obvious, since the spec will have to be changed to make the verification go through.
      - pcwalton 9y ago
        > If you define out-of-bounds writes to lead to memory corruption, your compiled code doesn't get any slower. Yes, it does, because some optimizations now become invalid. For example, a compiler would no longer allowed to delete a provably out-of-bounds write. This happens all the time. I don't think there's a lot of practical value in changing the definition of some kinds of undefined behavior to "memory corruption" (however defined) in the first place.

pcwalton 9y ago

> A good compiler might define its behavior. Just because the spec leaves things undefined doesn't mean the compiler should. All indications are that it's not possible to eliminate undefined behavior from C and C++ without significantly regressing performance. > Arguably a JS VM written in C++ may be vulnerable until the compiler is proven not to be. Vulnerabilities in JS engines are enormously more likely to be the result of undefined behavior in C++ than the result of C++ compiler miscompilations. As I said, eliminating miscompilations in LLVM/clang does nothing to address the problems of C++ UB.

yorwba 9y ago
Defining undefined behavior is very different from eliminating it. Every time a compiler compiles code that could potentially invoke UB, it defines what the UB means in that context. If you make the specific way the compiler handles certain cases of UB part of the spec (e.g. overflow wraps around, who cares about sign-magnitude anyway?), then programmers using that compiler can rely on these specifics to write code that does something sensible even when UB is invoked.
- Ded7xSEoPKYNsDd 9y ago
  The compiled code is also a lot slower. https://www.cis.upenn.edu/acg/softbound/ https://www.cis.upenn.edu/acg/softbound/
  - yorwba 9y ago
    Only if you want to define the undefined behavior to be safe. If you define out-of-bounds writes to lead to memory corruption, your compiled code doesn't get any slower. My point is that you can write your compiler spec to make explicit how exactly various kinds of UB are actually implemented, which then allows you to program to that spec and know that e.g. your overflowing bounds check is not completely eliminated from the program, but instead compiled into the machine instructions you had in mind. If a compiler is verified to conform to such a specification, unintended changes in handling UB will be very obvious, since the spec will have to be changed to make the verification go through.
    - pcwalton 9y ago
      > If you define out-of-bounds writes to lead to memory corruption, your compiled code doesn't get any slower. Yes, it does, because some optimizations now become invalid. For example, a compiler would no longer allowed to delete a provably out-of-bounds write. This happens all the time. I don't think there's a lot of practical value in changing the definition of some kinds of undefined behavior to "memory corruption" (however defined) in the first place.