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 insta

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.