int main(int argc, char **argv) {
unsigned long a[1];
a[3] = 0x7ffff7b36cebUL;
return 0;
}
It makes another program crashed
The array a is only one element long, so using a[3] is according to C programming language standard, undefined behavior
C and C++ have hundreds of rules for avoiding undefined behavior. They’re mostly common sense:
But the compiler does not enforce these rules; it has no obligation to detect even blatant violations. Indeed, the preceding program compiles without errors or warnings. The responsibility for avoiding undefined behavior falls entirely on you, the programmer.
So C and C++ put programmers in an awkward position: those languages are the industry standards for systems programming, but the demands they place on programmers all but guarantee a steady stream of crashes and security problems. Answering our mystery just raises a bigger question: can’t we do any better?
당신의 짐을 덜어줄 러스트
병렬 프로그래밍
그럼에도 빠른 속도.
This, finally, is our first opening quote. Rust shares the ambitions Bjarne Stroustrup articulates for C++ in his paper “Abstraction and the C++ Machine Model”:
In general, C++ implementations obey the zero-overhead principle:
What you don’t use, you don’t pay for. And further: What you do use, you couldn’t hand code any better.
일반적으로,C++구현은 오버헤드 제로의 원칙을 따른다.
사용하지 않는 것에 지불할 필요가 없고, 더 나아가, 사용하는 것에는 이보다 더 좋을 수는 없는 코딩을 한다.
Systems programming is often concerned with pushing the machine to its limits. For video games, the entire machine should be devoted to creating the best experience for the player. For web browsers, the efficiency of the browser sets the ceiling on what content authors can do. Within the machine’s inherent limitations, as much memory and processor attention as possible must be left to the content itself. The same principle applies to operating systems: the kernel should make the machine’s resources available to user programs, not consume them itself.