c++ - C/C++中的 "safe"和 "unsafe"代码是什么？

Question

C/C++ 中的“安全”和“不安全”代码有什么区别？

我在文章中读到“C++ 在导致严重安全漏洞的方面是不安全的”:How Rust Compares to Other Languages and More .不安全代码有什么不安全之处？

Answer 1

我相信 John Regehr 的文章 A Guide to Undefined Behavior in C and C++, Part 1很好地概述了文章的内容:

Programming languages typically make a distinction between normal program actions and erroneous actions. For Turing-complete languages we cannot reliably decide offline whether a program has the potential to execute an error; we have to just run it and see.

In a safe programming language, errors are trapped as they happen. Java, for example, is largely safe via its exception system. In an unsafe programming language, errors are not trapped. Rather, after executing an erroneous operation the program keeps going, but in a silently faulty way that may have observable consequences later on. Luca Cardelli’s article on type systems has a nice clear introduction to these issues. C and C++ are unsafe in a strong sense: executing an erroneous operation causes the entire program to be meaningless, as opposed to just the erroneous operation having an unpredictable result. In these languages erroneous operations are said to have undefined behavior.

因此，一旦我们进入未定义行为领域，我们现在就有了“不安全” 代码。另一篇将未定义行为视为不安全代码的好文章是 What Every C Programmer Should Know About Undefined Behavior #2/3 :

In Part 1 of our series, we discussed what undefined behavior is, and how it allows C and C++ compilers to produce higher performance applications than "safe" languages. This post talks about how "unsafe" C really is, explaining some of the highly surprising effects that undefined behavior can cause. In Part #3, we talk about what friendly compilers can do to mitigate some of the surprise, even if they aren't required to.

I like to call this "Why undefined behavior is often a scary and terrible thing for C programmers". :-)

C 和 C++ 由各自的标准和 we can find links to the latest ones here 指定那些标准将许多行为指定为未定义的行为。这基本上意味着行为是不可预测的。 C++ 标准定义未定义行为如下:

behavior for which this International Standard imposes no requirements [ Note: Undefined behavior may be expected when this International Standard omits any explicit definition of behavior or when a program uses an erroneous construct or erroneous data. Permissible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message). Many erroneous program constructs do not engender undefined behavior; they are required to be diagnosed. —end note ]

编译器不需要为未定义的行为提供诊断，我们可以找到许多未定义的行为导致安全漏洞的案例，其中一个比较知名的案例可能是 Linux kernel null pointer check removal :

The idea is to look for code that becomes dead when a C/C++ compiler is smart about exploiting undefined behavior. The classic example of this class of error was found in the Linux kernel several years ago. The code was basically:

struct foo *s = ...;
int x = s->f;
if (!s) return ERROR;
... use s ...

The problem is that the dereference of s in line 2 permits a compiler to infer that s is not null (if the pointer is null then the function is undefined; the compiler can simply ignore this case). Thus, the null check in line 3 gets silently optimized away and now the kernel contains an exploitable bug if an attacker can find a way to invoke this code with a null pointer

大多数时候避免未定义的行为是一种良好的编码习惯:

• 不要取消引用空指针
• 不要越界访问数组
• 不要use uninitialized variables
• 等...

并使用正确的工具，例如 ubsan但可能会有一些模糊的情况，例如 infinite loops许多开发人员可能会感到惊讶。