3 ms·

Computer languages are languages in which is written by people and interpreted by machines (and people). The argument: 'you shouldn't have written the code tha

Computer languages are languages in which is written by people and interpreted by machines (and people). The argument: 'you shouldn't have written the code that way, because it breaks a rule stated in this large UB book' is a bit petty to say the least. What about making it (almost) impossible to write UB code, wouldn't that be better for all? In the example shown, the compiler could simply throw an error stating that signed integers are not fit to be used as array indexes. Yes, such change of rules in the language would break backward compatibility, but adapting such code to the new rules would be a benefit anyway.

UncleMeat 3y ago
> What about making it (almost) impossible to write UB code This is not possible without pessimizing a significant portion of the architecture targets and also causing major slowdowns across all architectures. Dereferencing a pointer to a deleted object is UB. How are you going to test for this at runtime. ASan is already a huge amount of overhead and it isn't even guaranteed to detect UaF. > In the example shown, the compiler could simply throw an error stating that signed integers are not fit to be used as array indexes. Are unsigned indexes fit to be used? Reading an array out of bounds is UB and arrays don't carry their lengths with them.
- nuancebydefault 3y ago
  >this is not possible without... Hence the (almost) > Are unsigned indexes fit to be used? More fit than signed ones, clearly shown in the example in the article where a check was removed by the compiler's optimizer.
  - UncleMeat 3y ago
    I don't think that the (almost) is right here. UaF is a huge source of UB in C and C++. There are two ways to make UaF almost impossible: either a total adoption of Rust-style lifetime checking, which is not a possible transition for the large majority of existing code, or runtime checks that have large and unacceptable performance overhead. The overhead doesn't come from some a few weird corner cases that you can avoid in ordinary development. The overhead would come from core components.
    - nuancebydefault 3y ago
      I agree with all you wrote. Indeed full C array out of bounds checks or avoidance would not the way to go, for reasons you mentioned. Not to mention so many other modes of memory unsafety. But it is not exactly the point I tried to make. In the example code the article presents, there was an opportunity for C to improve the language to make it safer. Instead, the compiler writers decided to make sure this unwanted optimization would not happen by making the compiler more clever and hence heavier, so as to avoid this particular case of UB when using an improved compiler. Still, the C/C++ committee would wave away any critique with: don't use this language in the wrong (UB) way and complain.
ooterness 3y ago
> What about making it (almost) impossible to write UB code, wouldn't that be better for all? Congratulations, you have invented Rust.
- nuancebydefault 3y ago
  My take is that it would have been better for c/c++ to gradually improve the language rather than almost purist-wise stick to strict backward compatability. Want to compile your old code without changes? Use an older compiler or a backward compatibility switch of a newer compiler.

UncleMeat 3y ago

> What about making it (almost) impossible to write UB code This is not possible without pessimizing a significant portion of the architecture targets and also causing major slowdowns across all architectures. Dereferencing a pointer to a deleted object is UB. How are you going to test for this at runtime. ASan is already a huge amount of overhead and it isn't even guaranteed to detect UaF. > In the example shown, the compiler could simply throw an error stating that signed integers are not fit to be used as array indexes. Are unsigned indexes fit to be used? Reading an array out of bounds is UB and arrays don't carry their lengths with them.

nuancebydefault 3y ago
>this is not possible without... Hence the (almost) > Are unsigned indexes fit to be used? More fit than signed ones, clearly shown in the example in the article where a check was removed by the compiler's optimizer.
- UncleMeat 3y ago
  I don't think that the (almost) is right here. UaF is a huge source of UB in C and C++. There are two ways to make UaF almost impossible: either a total adoption of Rust-style lifetime checking, which is not a possible transition for the large majority of existing code, or runtime checks that have large and unacceptable performance overhead. The overhead doesn't come from some a few weird corner cases that you can avoid in ordinary development. The overhead would come from core components.
  - nuancebydefault 3y ago
    I agree with all you wrote. Indeed full C array out of bounds checks or avoidance would not the way to go, for reasons you mentioned. Not to mention so many other modes of memory unsafety. But it is not exactly the point I tried to make. In the example code the article presents, there was an opportunity for C to improve the language to make it safer. Instead, the compiler writers decided to make sure this unwanted optimization would not happen by making the compiler more clever and hence heavier, so as to avoid this particular case of UB when using an improved compiler. Still, the C/C++ committee would wave away any critique with: don't use this language in the wrong (UB) way and complain.

ooterness 3y ago

> What about making it (almost) impossible to write UB code, wouldn't that be better for all? Congratulations, you have invented Rust.

nuancebydefault 3y ago
My take is that it would have been better for c/c++ to gradually improve the language rather than almost purist-wise stick to strict backward compatability. Want to compile your old code without changes? Use an older compiler or a backward compatibility switch of a newer compiler.