4 ms·

If nothing bad happens when something unsafe happens then code is safe. If you don't use the feature set that declares the code as unsafe then it's safe. A kni

If nothing bad happens when something unsafe happens then code is safe. If you don't use the feature set that declares the code as unsafe then it's safe. A knife is unsafe, but when a chef uses it correctly it's safe. As is code. It's only when you use syntax incorrectly does it become unsafe. A tightrope is still unsafe and now you're relying on the safety net to catch your fall. What declares the safety of the safety net? However both standards should apply. But as programming is now more rapid rather than a dedicated skill, prototyping of new code landing in production. We are tend to rapidly program ignoring the correct way to program and now relying on the language to do the checkup. That itself is still just as unsafe and now passing the buck of lousy code on to as a fault of the language itself. Safety doesn't come from the language. It can, mainly it comes from the code. Use syntax incorrectly and you have unsafe code in any language.

kstrauser 2y ago
We need to accept that humans are not capable of writing safe code in unsafe languages. Brilliant, dedicated, diligent programmers still write busted C code all the time. If the OpenBSD team still makes critical mistakes today, what hope do the rest of us have?
- kazinator 2y ago
  It is selection bias at work. Only programs in which an issue is found are the targets of reports like CVE.
kazinator 2y ago
Almost all code in an unsafe language will misbehave on bad inputs. The program is put together in a way such that it avoids stepping on those cases. For instance, by validating and diagnosing inputs so as to avoiding executing that code. You would think that a program which has been deemed "correct" cannot misuse any of its own code with undefined results. Alas, that is not the case. Such a program is called a "robust" program. A correct program is one that meets all of its functional requirements; does eveything right with correct inputs. Whether robustness is required for correctness depends entirely on how the program is specified: does the specification explicitly call for robustness (grace on bad inputs) or not? For instance, the memcpy() function in your C library is a correct program (hopefully). When you use it correctly, it does its specified job. Most implementations of it are not robust, though. Most memcpy functions cheerfully accept overlapping objects and do something, and are easily crashed by bad pointers. Robustness is related to security. It is often in the areas of the software that lack robustness that attackers find exploitable surfaces! Safe languages contribute robustness to programs. It's as if the requirements were added to the spec of every program. The programmers working with these languages, and their users, get accustomed to this and then expect robustness out of programs as a tacit requirement. Note that an incorrect program can be robust! A program that due to some coding mistake or misunderstanding calculates the wrong thing for correct inputs (not meeting a functional requirement) can still be impervious to misuse. So in a nutshell, safety is more concerned with robustness than correctness. That's why we can talk about languages and libraries being safe, in the absence of a program being specified. Those tools are still safe when they are used to put together a program that doesn't meet its functional requirements. The safety mechanisms in safe languages may not be enoguh for some desirable level of robustness. Users don't want programs to stop with a diagnostic message because they gave bad inputs. Modern safe languages have tools like exception handling. Some wrongheaded programmers think that just because the default robustness provided by safe languages is not always good enough for many kinds of professional or industrial applications, those robustness features are therefore not worth it. ("If I'm going to have to check for bad inputs and take special action, what's the use of the language doing the checking robust.") The safe language can make it much easier to do that, though. For instance, we can often let an entire module execute freely and just catch an exception in one place. Say, inside a CAD program, some calculation over a model could divide by zero. We just catch that somewhere, put up a dialog (or log something in a log window) and the CAD program keeps running.

kstrauser 2y ago

We need to accept that humans are not capable of writing safe code in unsafe languages. Brilliant, dedicated, diligent programmers still write busted C code all the time. If the OpenBSD team still makes critical mistakes today, what hope do the rest of us have?

kazinator 2y ago
It is selection bias at work. Only programs in which an issue is found are the targets of reports like CVE.

kazinator 2y ago

Almost all code in an unsafe language will misbehave on bad inputs. The program is put together in a way such that it avoids stepping on those cases. For instance, by validating and diagnosing inputs so as to avoiding executing that code. You would think that a program which has been deemed "correct" cannot misuse any of its own code with undefined results. Alas, that is not the case. Such a program is called a "robust" program. A correct program is one that meets all of its functional requirements; does eveything right with correct inputs. Whether robustness is required for correctness depends entirely on how the program is specified: does the specification explicitly call for robustness (grace on bad inputs) or not? For instance, the memcpy() function in your C library is a correct program (hopefully). When you use it correctly, it does its specified job. Most implementations of it are not robust, though. Most memcpy functions cheerfully accept overlapping objects and do something, and are easily crashed by bad pointers. Robustness is related to security. It is often in the areas of the software that lack robustness that attackers find exploitable surfaces! Safe languages contribute robustness to programs. It's as if the requirements were added to the spec of every program. The programmers working with these languages, and their users, get accustomed to this and then expect robustness out of programs as a tacit requirement. Note that an incorrect program can be robust! A program that due to some coding mistake or misunderstanding calculates the wrong thing for correct inputs (not meeting a functional requirement) can still be impervious to misuse. So in a nutshell, safety is more concerned with robustness than correctness. That's why we can talk about languages and libraries being safe, in the absence of a program being specified. Those tools are still safe when they are used to put together a program that doesn't meet its functional requirements. The safety mechanisms in safe languages may not be enoguh for some desirable level of robustness. Users don't want programs to stop with a diagnostic message because they gave bad inputs. Modern safe languages have tools like exception handling. Some wrongheaded programmers think that just because the default robustness provided by safe languages is not always good enough for many kinds of professional or industrial applications, those robustness features are therefore not worth it. ("If I'm going to have to check for bad inputs and take special action, what's the use of the language doing the checking robust.") The safe language can make it much easier to do that, though. For instance, we can often let an entire module execute freely and just catch an exception in one place. Say, inside a CAD program, some calculation over a model could divide by zero. We just catch that somewhere, put up a dialog (or log something in a log window) and the CAD program keeps running.