stack smash protection => stack smashing protection

Author: Ariel Ben-Yehuda

compiler/rustc_session/src/options.rs

@@ -2188,7 +2188,7 @@ options! {
         "how to handle split-debuginfo, a platform-specific option"),
     #[rustc_lint_opt_deny_field_access("use `Session::stack_protector` instead of this field")]
     stack_protector: Option<StackProtector> = (None, parse_stack_protector, [TRACKED],
-        "control stack smash protection strategy (`rustc --print stack-protector-strategies` for details)"),
+        "control stack smashing protection strategy (`rustc --print stack-protector-strategies` for details)"),
     strip: Strip = (Strip::None, parse_strip, [UNTRACKED],
         "tell the linker which information to strip (`none` (default), `debuginfo` or `symbols`)"),
     symbol_mangling_version: Option<SymbolManglingVersion> = (None,
@@ -2666,7 +2666,7 @@ written to standard error output)"),
         "hash algorithm of source files in debug info (`md5`, `sha1`, or `sha256`)"),
     #[rustc_lint_opt_deny_field_access("use `Session::stack_protector` instead of this field")]
     stack_protector: Option<StackProtector> = (None, parse_stack_protector, [TRACKED],
-        "control stack smash protection strategy (`rustc --print stack-protector-strategies` for details)"),
+        "control stack smashing protection strategy (`rustc --print stack-protector-strategies` for details)"),
     staticlib_allow_rdylib_deps: bool = (false, parse_bool, [TRACKED],
         "allow staticlibs to have rust dylib dependencies"),
     staticlib_prefer_dynamic: bool = (false, parse_bool, [TRACKED],

tests/assembly-llvm/stack-protector/stack-protector-heuristics-effect-windows-32bit.rs

@@ -114,7 +114,7 @@ pub fn local_var_addr_used_indirectly(f: fn(bool)) {
 
     // This function takes the address of a local variable taken. Although this
     // address is never used as a way to refer to stack memory, the `strong`
-    // heuristic adds stack smash protection. This is also the case in C++:
+    // heuristic adds stack smashing protection. This is also the case in C++:
     // ```
     // cat << EOF | clang++ -O2 -fstack-protector-strong -S -x c++ - -o - | grep stack_chk
     // #include <cstdint>
@@ -182,7 +182,7 @@ pub fn local_var_addr_taken_used_locally_only(factory: fn() -> i32, sink: fn(i32
 
     // Even though the local variable conceptually has its address taken, as
     // it's passed by reference to the trait function, the use of the reference
-    // is easily inlined. There is therefore no stack smash protection even with
+    // is easily inlined. There is therefore no stack smashing protection even with
     // the `strong` heuristic.
 
     // all: __security_check_cookie

tests/assembly-llvm/stack-protector/stack-protector-heuristics-effect-windows-64bit.rs

@@ -113,7 +113,7 @@ pub fn local_var_addr_used_indirectly(f: fn(bool)) {
 
     // This function takes the address of a local variable taken. Although this
     // address is never used as a way to refer to stack memory, the `strong`
-    // heuristic adds stack smash protection. This is also the case in C++:
+    // heuristic adds stack smashing protection. This is also the case in C++:
     // ```
     // cat << EOF | clang++ -O2 -fstack-protector-strong -S -x c++ - -o - | grep stack_chk
     // #include <cstdint>
@@ -186,7 +186,7 @@ pub fn local_var_addr_taken_used_locally_only(factory: fn() -> i32, sink: fn(i32
 
     // Even though the local variable conceptually has its address taken, as
     // it's passed by reference to the trait function, the use of the reference
-    // is easily inlined. There is therefore no stack smash protection even with
+    // is easily inlined. There is therefore no stack smashing protection even with
     // the `strong` heuristic.
 
     // all: __security_check_cookie

tests/assembly-llvm/stack-protector/stack-protector-heuristics-effect.rs

@@ -9,7 +9,7 @@
 //@ [none] compile-flags: -C stack-protector=none
 //@ compile-flags: -C opt-level=2 -Z merge-functions=disabled
 
-// NOTE: the heuristics for stack smash protection inappropriately rely on types in LLVM IR,
+// NOTE: the heuristics for stack smashing protection inappropriately rely on types in LLVM IR,
 // despite those types having no semantic meaning. This means that the `basic` and `strong`
 // settings do not behave in a coherent way. This is a known issue in LLVM.
 // See comments on https://github.com/rust-lang/rust/issues/114903.
@@ -120,7 +120,7 @@ pub fn local_var_addr_used_indirectly(f: fn(bool)) {
 
     // This function takes the address of a local variable taken. Although this
     // address is never used as a way to refer to stack memory, the `strong`
-    // heuristic adds stack smash protection. This is also the case in C++:
+    // heuristic adds stack smashing protection. This is also the case in C++:
     // ```
     // cat << EOF | clang++ -O2 -fstack-protector-strong -S -x c++ - -o - | grep stack_chk
     // #include <cstdint>
@@ -171,7 +171,7 @@ pub fn local_var_addr_taken_used_locally_only(factory: fn() -> i32, sink: fn(i32
 
     // Even though the local variable conceptually has its address taken, as
     // it's passed by reference to the trait function, the use of the reference
-    // is easily inlined. There is therefore no stack smash protection even with
+    // is easily inlined. There is therefore no stack smashing protection even with
     // the `strong` heuristic.
 
     // all: __stack_chk_fail

tests/assembly-llvm/stack-protector/stack-protector-target-support.rs

@@ -1,4 +1,4 @@
-// Test that stack smash protection code is emitted for all tier1 and tier2
+// Test that stack smashing protection code is emitted for all tier1 and tier2
 // targets, with the exception of nvptx64-nvidia-cuda
 //
 //@ add-minicore