…r environment (-funsigned-char)

0c78e49 tests: Switch one of the Travis jobs to an unsigned char environment (-funsigned-char) (practicalswift)

Pull request description:

  Switch one of the Travis jobs to an unsigned char environment (`-funsigned-char`).

  This will help us catch errors due to code written under the assumption that `char` has the same value range as `signed char`.

  The signedness of `char` is implementation-defined.

  Example:

  ```
  $ uname -a
  Linux […] x86_64 x86_64 x86_64 GNU/Linux
  $ cat foo.cpp
  #include <iostream>

  int main() {
      char c;
      std::cin >> c;
      int i = (unsigned char)c;
      std::cout << i << "\n";
  }
  $ clang++ -o foo foo.cpp
  $ echo -e "\xff" | ./foo
  255
  $ clang++ -fsigned-char -o foo foo.cpp
  $ echo -e "\xff" | ./foo
  255
  $ clang++ -funsigned-char -o foo foo.cpp
  $ echo -e "\xff" | ./foo
  255
  $ cat bar.cpp
  #include <iostream>

  int main() {
      char c;
      std::cin >> c;
      int i = c;
      std::cout << i << "\n";
  }
  $ clang++ -o bar bar.cpp
  $ echo -e "\xff" | ./bar
  -1
  $ clang++ -fsigned-char -o bar bar.cpp
  $ echo -e "\xff" | ./bar
  -1
  $ clang++ -funsigned-char -o bar bar.cpp
  $ echo -e "\xff" | ./bar
  255
  ```

  `gcc` chars:
  * signed: alpha, hppa, ia64, m68k, mips, sh, sparc, x86
  * unsigned: arm, powerpc, s390

  About `-funsigned-char`:

  > Let the type "char" be unsigned, like "unsigned char".
  >
  > Each kind of machine has a default for what "char" should be.  It is either like "unsigned char" by default or like "signed char" by default.
  >
  > Ideally, a portable program should always use "signed char" or "unsigned char" when it depends on the signedness of an object.  But many programs have been written to use plain "char" and expect it to be signed, or expect it to be unsigned, depending on the machines they were written for.
  >
  > This option, and its inverse, let you make such a program work with the opposite default. The type "char" is always a distinct type from each of "signed char" or "unsigned char", even though its behavior is always just like one of those two.

ACKs for top commit:
  laanwj:
    ACK 0c78e49

Tree-SHA512: ba04590415c0bb9a0bbd348623e57068f75274f53da7247d5c5ecad82e365a5b45893a4a491d318e82a8feb6a25f019d46e01990afb33162e2c9740d33a343d7

…ned char environment (-funsigned-char)

0c78e49 tests: Switch one of the Travis jobs to an unsigned char environment (-funsigned-char) (practicalswift)

Pull request description:

  Switch one of the Travis jobs to an unsigned char environment (`-funsigned-char`).

  This will help us catch errors due to code written under the assumption that `char` has the same value range as `signed char`.

  The signedness of `char` is implementation-defined.

  Example:

  ```
  $ uname -a
  Linux […] x86_64 x86_64 x86_64 GNU/Linux
  $ cat foo.cpp
  #include <iostream>

  int main() {
      char c;
      std::cin >> c;
      int i = (unsigned char)c;
      std::cout << i << "\n";
  }
  $ clang++ -o foo foo.cpp
  $ echo -e "\xff" | ./foo
  255
  $ clang++ -fsigned-char -o foo foo.cpp
  $ echo -e "\xff" | ./foo
  255
  $ clang++ -funsigned-char -o foo foo.cpp
  $ echo -e "\xff" | ./foo
  255
  $ cat bar.cpp
  #include <iostream>

  int main() {
      char c;
      std::cin >> c;
      int i = c;
      std::cout << i << "\n";
  }
  $ clang++ -o bar bar.cpp
  $ echo -e "\xff" | ./bar
  -1
  $ clang++ -fsigned-char -o bar bar.cpp
  $ echo -e "\xff" | ./bar
  -1
  $ clang++ -funsigned-char -o bar bar.cpp
  $ echo -e "\xff" | ./bar
  255
  ```

  `gcc` chars:
  * signed: alpha, hppa, ia64, m68k, mips, sh, sparc, x86
  * unsigned: arm, powerpc, s390

  About `-funsigned-char`:

  > Let the type "char" be unsigned, like "unsigned char".
  >
  > Each kind of machine has a default for what "char" should be.  It is either like "unsigned char" by default or like "signed char" by default.
  >
  > Ideally, a portable program should always use "signed char" or "unsigned char" when it depends on the signedness of an object.  But many programs have been written to use plain "char" and expect it to be signed, or expect it to be unsigned, depending on the machines they were written for.
  >
  > This option, and its inverse, let you make such a program work with the opposite default. The type "char" is always a distinct type from each of "signed char" or "unsigned char", even though its behavior is always just like one of those two.

ACKs for top commit:
  laanwj:
    ACK 0c78e49

Tree-SHA512: ba04590415c0bb9a0bbd348623e57068f75274f53da7247d5c5ecad82e365a5b45893a4a491d318e82a8feb6a25f019d46e01990afb33162e2c9740d33a343d7

…se of uninitialized memory

870f0cd build: Add MemorySanitizer (MSan) in Travis to detect use of uninitialized memory (practicalswift)

Pull request description:

  Add MemorySanitizer (MSan) in Travis to detect use of uninitialized memory.

  First UBSan, then ASan followed by TSan... and now: yes, the wait is over -- **MSan is finally here!** :)

  Some historical context:
  * 2017: Continuous compilation with Clang Thread Safety analysis enabled (#10866, #10923)
  * 2018: Continuous testing with trapping on signed integer overflows (`-ftrapv`) (#12686)
  * 2018: Continuous testing of use of locale dependent functions (#13041)
  * 2018: Continuous testing of format strings (#13705)
  * 2018: Continuous compilation with MSVC `TreatWarningAsError` (#14151)
  * 2018: Continuous testing under UndefinedBehaviorSanitizer – UBSan (#14252, #14673, #17006)
  * 2018: Continuous testing under AddressSanitizer – ASan (#14794, #17205, #17674)
  * 2018: Continuous testing under ThreadSanitizer – TSan (#14829)
  * 2019: Continuous testing in an unsigned char environment (`-funsigned-char`) (#15134)
  * 2019: Continuous compile-time testing of assumptions we're making (#15391)
  * 2019: Continuous testing of fuzz test cases under Valgrind (#17633, #18159, #18166)
  * 2020: Finally... MemorySanitizer – MSAN! :)

  What is the next step? What tools should we add to CI to keep bugs from entering `master`? :)

ACKs for top commit:
  MarcoFalke:
    ACK 870f0cd

Tree-SHA512: 38327c8b75679d97d469fe42e704cacd1217447a5a603701dd8a58ee50b3be2c10248f8d68a479ed081c0c4b254589d3081c9183f991640b06ef689061f75578

…ned char environment (-funsigned-char)

0c78e49 tests: Switch one of the Travis jobs to an unsigned char environment (-funsigned-char) (practicalswift)

Pull request description:

  Switch one of the Travis jobs to an unsigned char environment (`-funsigned-char`).

  This will help us catch errors due to code written under the assumption that `char` has the same value range as `signed char`.

  The signedness of `char` is implementation-defined.

  Example:

  ```
  $ uname -a
  Linux […] x86_64 x86_64 x86_64 GNU/Linux
  $ cat foo.cpp
  #include <iostream>

  int main() {
      char c;
      std::cin >> c;
      int i = (unsigned char)c;
      std::cout << i << "\n";
  }
  $ clang++ -o foo foo.cpp
  $ echo -e "\xff" | ./foo
  255
  $ clang++ -fsigned-char -o foo foo.cpp
  $ echo -e "\xff" | ./foo
  255
  $ clang++ -funsigned-char -o foo foo.cpp
  $ echo -e "\xff" | ./foo
  255
  $ cat bar.cpp
  #include <iostream>

  int main() {
      char c;
      std::cin >> c;
      int i = c;
      std::cout << i << "\n";
  }
  $ clang++ -o bar bar.cpp
  $ echo -e "\xff" | ./bar
  -1
  $ clang++ -fsigned-char -o bar bar.cpp
  $ echo -e "\xff" | ./bar
  -1
  $ clang++ -funsigned-char -o bar bar.cpp
  $ echo -e "\xff" | ./bar
  255
  ```

  `gcc` chars:
  * signed: alpha, hppa, ia64, m68k, mips, sh, sparc, x86
  * unsigned: arm, powerpc, s390

  About `-funsigned-char`:

  > Let the type "char" be unsigned, like "unsigned char".
  >
  > Each kind of machine has a default for what "char" should be.  It is either like "unsigned char" by default or like "signed char" by default.
  >
  > Ideally, a portable program should always use "signed char" or "unsigned char" when it depends on the signedness of an object.  But many programs have been written to use plain "char" and expect it to be signed, or expect it to be unsigned, depending on the machines they were written for.
  >
  > This option, and its inverse, let you make such a program work with the opposite default. The type "char" is always a distinct type from each of "signed char" or "unsigned char", even though its behavior is always just like one of those two.

ACKs for top commit:
  laanwj:
    ACK 0c78e49

Tree-SHA512: ba04590415c0bb9a0bbd348623e57068f75274f53da7247d5c5ecad82e365a5b45893a4a491d318e82a8feb6a25f019d46e01990afb33162e2c9740d33a343d7

…ned char environment (-funsigned-char)

0c78e49 tests: Switch one of the Travis jobs to an unsigned char environment (-funsigned-char) (practicalswift)

Pull request description:

  Switch one of the Travis jobs to an unsigned char environment (`-funsigned-char`).

  This will help us catch errors due to code written under the assumption that `char` has the same value range as `signed char`.

  The signedness of `char` is implementation-defined.

  Example:

  ```
  $ uname -a
  Linux […] x86_64 x86_64 x86_64 GNU/Linux
  $ cat foo.cpp
  #include <iostream>

  int main() {
      char c;
      std::cin >> c;
      int i = (unsigned char)c;
      std::cout << i << "\n";
  }
  $ clang++ -o foo foo.cpp
  $ echo -e "\xff" | ./foo
  255
  $ clang++ -fsigned-char -o foo foo.cpp
  $ echo -e "\xff" | ./foo
  255
  $ clang++ -funsigned-char -o foo foo.cpp
  $ echo -e "\xff" | ./foo
  255
  $ cat bar.cpp
  #include <iostream>

  int main() {
      char c;
      std::cin >> c;
      int i = c;
      std::cout << i << "\n";
  }
  $ clang++ -o bar bar.cpp
  $ echo -e "\xff" | ./bar
  -1
  $ clang++ -fsigned-char -o bar bar.cpp
  $ echo -e "\xff" | ./bar
  -1
  $ clang++ -funsigned-char -o bar bar.cpp
  $ echo -e "\xff" | ./bar
  255
  ```

  `gcc` chars:
  * signed: alpha, hppa, ia64, m68k, mips, sh, sparc, x86
  * unsigned: arm, powerpc, s390

  About `-funsigned-char`:

  > Let the type "char" be unsigned, like "unsigned char".
  >
  > Each kind of machine has a default for what "char" should be.  It is either like "unsigned char" by default or like "signed char" by default.
  >
  > Ideally, a portable program should always use "signed char" or "unsigned char" when it depends on the signedness of an object.  But many programs have been written to use plain "char" and expect it to be signed, or expect it to be unsigned, depending on the machines they were written for.
  >
  > This option, and its inverse, let you make such a program work with the opposite default. The type "char" is always a distinct type from each of "signed char" or "unsigned char", even though its behavior is always just like one of those two.

ACKs for top commit:
  laanwj:
    ACK 0c78e49

Tree-SHA512: ba04590415c0bb9a0bbd348623e57068f75274f53da7247d5c5ecad82e365a5b45893a4a491d318e82a8feb6a25f019d46e01990afb33162e2c9740d33a343d7

…ned char environment (-funsigned-char)

0c78e49 tests: Switch one of the Travis jobs to an unsigned char environment (-funsigned-char) (practicalswift)

Pull request description:

  Switch one of the Travis jobs to an unsigned char environment (`-funsigned-char`).

  This will help us catch errors due to code written under the assumption that `char` has the same value range as `signed char`.

  The signedness of `char` is implementation-defined.

  Example:

  ```
  $ uname -a
  Linux […] x86_64 x86_64 x86_64 GNU/Linux
  $ cat foo.cpp
  #include <iostream>

  int main() {
      char c;
      std::cin >> c;
      int i = (unsigned char)c;
      std::cout << i << "\n";
  }
  $ clang++ -o foo foo.cpp
  $ echo -e "\xff" | ./foo
  255
  $ clang++ -fsigned-char -o foo foo.cpp
  $ echo -e "\xff" | ./foo
  255
  $ clang++ -funsigned-char -o foo foo.cpp
  $ echo -e "\xff" | ./foo
  255
  $ cat bar.cpp
  #include <iostream>

  int main() {
      char c;
      std::cin >> c;
      int i = c;
      std::cout << i << "\n";
  }
  $ clang++ -o bar bar.cpp
  $ echo -e "\xff" | ./bar
  -1
  $ clang++ -fsigned-char -o bar bar.cpp
  $ echo -e "\xff" | ./bar
  -1
  $ clang++ -funsigned-char -o bar bar.cpp
  $ echo -e "\xff" | ./bar
  255
  ```

  `gcc` chars:
  * signed: alpha, hppa, ia64, m68k, mips, sh, sparc, x86
  * unsigned: arm, powerpc, s390

  About `-funsigned-char`:

  > Let the type "char" be unsigned, like "unsigned char".
  >
  > Each kind of machine has a default for what "char" should be.  It is either like "unsigned char" by default or like "signed char" by default.
  >
  > Ideally, a portable program should always use "signed char" or "unsigned char" when it depends on the signedness of an object.  But many programs have been written to use plain "char" and expect it to be signed, or expect it to be unsigned, depending on the machines they were written for.
  >
  > This option, and its inverse, let you make such a program work with the opposite default. The type "char" is always a distinct type from each of "signed char" or "unsigned char", even though its behavior is always just like one of those two.

ACKs for top commit:
  laanwj:
    ACK 0c78e49

Tree-SHA512: ba04590415c0bb9a0bbd348623e57068f75274f53da7247d5c5ecad82e365a5b45893a4a491d318e82a8feb6a25f019d46e01990afb33162e2c9740d33a343d7

…ned char environment (-funsigned-char)

0c78e49 tests: Switch one of the Travis jobs to an unsigned char environment (-funsigned-char) (practicalswift)

Pull request description:

  Switch one of the Travis jobs to an unsigned char environment (`-funsigned-char`).

  This will help us catch errors due to code written under the assumption that `char` has the same value range as `signed char`.

  The signedness of `char` is implementation-defined.

  Example:

  ```
  $ uname -a
  Linux […] x86_64 x86_64 x86_64 GNU/Linux
  $ cat foo.cpp
  #include <iostream>

  int main() {
      char c;
      std::cin >> c;
      int i = (unsigned char)c;
      std::cout << i << "\n";
  }
  $ clang++ -o foo foo.cpp
  $ echo -e "\xff" | ./foo
  255
  $ clang++ -fsigned-char -o foo foo.cpp
  $ echo -e "\xff" | ./foo
  255
  $ clang++ -funsigned-char -o foo foo.cpp
  $ echo -e "\xff" | ./foo
  255
  $ cat bar.cpp
  #include <iostream>

  int main() {
      char c;
      std::cin >> c;
      int i = c;
      std::cout << i << "\n";
  }
  $ clang++ -o bar bar.cpp
  $ echo -e "\xff" | ./bar
  -1
  $ clang++ -fsigned-char -o bar bar.cpp
  $ echo -e "\xff" | ./bar
  -1
  $ clang++ -funsigned-char -o bar bar.cpp
  $ echo -e "\xff" | ./bar
  255
  ```

  `gcc` chars:
  * signed: alpha, hppa, ia64, m68k, mips, sh, sparc, x86
  * unsigned: arm, powerpc, s390

  About `-funsigned-char`:

  > Let the type "char" be unsigned, like "unsigned char".
  >
  > Each kind of machine has a default for what "char" should be.  It is either like "unsigned char" by default or like "signed char" by default.
  >
  > Ideally, a portable program should always use "signed char" or "unsigned char" when it depends on the signedness of an object.  But many programs have been written to use plain "char" and expect it to be signed, or expect it to be unsigned, depending on the machines they were written for.
  >
  > This option, and its inverse, let you make such a program work with the opposite default. The type "char" is always a distinct type from each of "signed char" or "unsigned char", even though its behavior is always just like one of those two.

ACKs for top commit:
  laanwj:
    ACK 0c78e49

Tree-SHA512: ba04590415c0bb9a0bbd348623e57068f75274f53da7247d5c5ecad82e365a5b45893a4a491d318e82a8feb6a25f019d46e01990afb33162e2c9740d33a343d7

…ned char environment (-funsigned-char)

0c78e49 tests: Switch one of the Travis jobs to an unsigned char environment (-funsigned-char) (practicalswift)

Pull request description:

  Switch one of the Travis jobs to an unsigned char environment (`-funsigned-char`).

  This will help us catch errors due to code written under the assumption that `char` has the same value range as `signed char`.

  The signedness of `char` is implementation-defined.

  Example:

  ```
  $ uname -a
  Linux […] x86_64 x86_64 x86_64 GNU/Linux
  $ cat foo.cpp
  #include <iostream>

  int main() {
      char c;
      std::cin >> c;
      int i = (unsigned char)c;
      std::cout << i << "\n";
  }
  $ clang++ -o foo foo.cpp
  $ echo -e "\xff" | ./foo
  255
  $ clang++ -fsigned-char -o foo foo.cpp
  $ echo -e "\xff" | ./foo
  255
  $ clang++ -funsigned-char -o foo foo.cpp
  $ echo -e "\xff" | ./foo
  255
  $ cat bar.cpp
  #include <iostream>

  int main() {
      char c;
      std::cin >> c;
      int i = c;
      std::cout << i << "\n";
  }
  $ clang++ -o bar bar.cpp
  $ echo -e "\xff" | ./bar
  -1
  $ clang++ -fsigned-char -o bar bar.cpp
  $ echo -e "\xff" | ./bar
  -1
  $ clang++ -funsigned-char -o bar bar.cpp
  $ echo -e "\xff" | ./bar
  255
  ```

  `gcc` chars:
  * signed: alpha, hppa, ia64, m68k, mips, sh, sparc, x86
  * unsigned: arm, powerpc, s390

  About `-funsigned-char`:

  > Let the type "char" be unsigned, like "unsigned char".
  >
  > Each kind of machine has a default for what "char" should be.  It is either like "unsigned char" by default or like "signed char" by default.
  >
  > Ideally, a portable program should always use "signed char" or "unsigned char" when it depends on the signedness of an object.  But many programs have been written to use plain "char" and expect it to be signed, or expect it to be unsigned, depending on the machines they were written for.
  >
  > This option, and its inverse, let you make such a program work with the opposite default. The type "char" is always a distinct type from each of "signed char" or "unsigned char", even though its behavior is always just like one of those two.

ACKs for top commit:
  laanwj:
    ACK 0c78e49

Tree-SHA512: ba04590415c0bb9a0bbd348623e57068f75274f53da7247d5c5ecad82e365a5b45893a4a491d318e82a8feb6a25f019d46e01990afb33162e2c9740d33a343d7

…ned char environment (-funsigned-char)

0c78e49 tests: Switch one of the Travis jobs to an unsigned char environment (-funsigned-char) (practicalswift)

Pull request description:

  Switch one of the Travis jobs to an unsigned char environment (`-funsigned-char`).

  This will help us catch errors due to code written under the assumption that `char` has the same value range as `signed char`.

  The signedness of `char` is implementation-defined.

  Example:

  ```
  $ uname -a
  Linux […] x86_64 x86_64 x86_64 GNU/Linux
  $ cat foo.cpp
  #include <iostream>

  int main() {
      char c;
      std::cin >> c;
      int i = (unsigned char)c;
      std::cout << i << "\n";
  }
  $ clang++ -o foo foo.cpp
  $ echo -e "\xff" | ./foo
  255
  $ clang++ -fsigned-char -o foo foo.cpp
  $ echo -e "\xff" | ./foo
  255
  $ clang++ -funsigned-char -o foo foo.cpp
  $ echo -e "\xff" | ./foo
  255
  $ cat bar.cpp
  #include <iostream>

  int main() {
      char c;
      std::cin >> c;
      int i = c;
      std::cout << i << "\n";
  }
  $ clang++ -o bar bar.cpp
  $ echo -e "\xff" | ./bar
  -1
  $ clang++ -fsigned-char -o bar bar.cpp
  $ echo -e "\xff" | ./bar
  -1
  $ clang++ -funsigned-char -o bar bar.cpp
  $ echo -e "\xff" | ./bar
  255
  ```

  `gcc` chars:
  * signed: alpha, hppa, ia64, m68k, mips, sh, sparc, x86
  * unsigned: arm, powerpc, s390

  About `-funsigned-char`:

  > Let the type "char" be unsigned, like "unsigned char".
  >
  > Each kind of machine has a default for what "char" should be.  It is either like "unsigned char" by default or like "signed char" by default.
  >
  > Ideally, a portable program should always use "signed char" or "unsigned char" when it depends on the signedness of an object.  But many programs have been written to use plain "char" and expect it to be signed, or expect it to be unsigned, depending on the machines they were written for.
  >
  > This option, and its inverse, let you make such a program work with the opposite default. The type "char" is always a distinct type from each of "signed char" or "unsigned char", even though its behavior is always just like one of those two.

ACKs for top commit:
  laanwj:
    ACK 0c78e49

Tree-SHA512: ba04590415c0bb9a0bbd348623e57068f75274f53da7247d5c5ecad82e365a5b45893a4a491d318e82a8feb6a25f019d46e01990afb33162e2c9740d33a343d7

…ned char environment (-funsigned-char)

0c78e49 tests: Switch one of the Travis jobs to an unsigned char environment (-funsigned-char) (practicalswift)

Pull request description:

  Switch one of the Travis jobs to an unsigned char environment (`-funsigned-char`).

  This will help us catch errors due to code written under the assumption that `char` has the same value range as `signed char`.

  The signedness of `char` is implementation-defined.

  Example:

  ```
  $ uname -a
  Linux […] x86_64 x86_64 x86_64 GNU/Linux
  $ cat foo.cpp
  #include <iostream>

  int main() {
      char c;
      std::cin >> c;
      int i = (unsigned char)c;
      std::cout << i << "\n";
  }
  $ clang++ -o foo foo.cpp
  $ echo -e "\xff" | ./foo
  255
  $ clang++ -fsigned-char -o foo foo.cpp
  $ echo -e "\xff" | ./foo
  255
  $ clang++ -funsigned-char -o foo foo.cpp
  $ echo -e "\xff" | ./foo
  255
  $ cat bar.cpp
  #include <iostream>

  int main() {
      char c;
      std::cin >> c;
      int i = c;
      std::cout << i << "\n";
  }
  $ clang++ -o bar bar.cpp
  $ echo -e "\xff" | ./bar
  -1
  $ clang++ -fsigned-char -o bar bar.cpp
  $ echo -e "\xff" | ./bar
  -1
  $ clang++ -funsigned-char -o bar bar.cpp
  $ echo -e "\xff" | ./bar
  255
  ```

  `gcc` chars:
  * signed: alpha, hppa, ia64, m68k, mips, sh, sparc, x86
  * unsigned: arm, powerpc, s390

  About `-funsigned-char`:

  > Let the type "char" be unsigned, like "unsigned char".
  >
  > Each kind of machine has a default for what "char" should be.  It is either like "unsigned char" by default or like "signed char" by default.
  >
  > Ideally, a portable program should always use "signed char" or "unsigned char" when it depends on the signedness of an object.  But many programs have been written to use plain "char" and expect it to be signed, or expect it to be unsigned, depending on the machines they were written for.
  >
  > This option, and its inverse, let you make such a program work with the opposite default. The type "char" is always a distinct type from each of "signed char" or "unsigned char", even though its behavior is always just like one of those two.

ACKs for top commit:
  laanwj:
    ACK 0c78e49

Tree-SHA512: ba04590415c0bb9a0bbd348623e57068f75274f53da7247d5c5ecad82e365a5b45893a4a491d318e82a8feb6a25f019d46e01990afb33162e2c9740d33a343d7

…etect use of uninitialized memory

870f0cd build: Add MemorySanitizer (MSan) in Travis to detect use of uninitialized memory (practicalswift)

Pull request description:

  Add MemorySanitizer (MSan) in Travis to detect use of uninitialized memory.

  First UBSan, then ASan followed by TSan... and now: yes, the wait is over -- **MSan is finally here!** :)

  Some historical context:
  * 2017: Continuous compilation with Clang Thread Safety analysis enabled (bitcoin#10866, bitcoin#10923)
  * 2018: Continuous testing with trapping on signed integer overflows (`-ftrapv`) (bitcoin#12686)
  * 2018: Continuous testing of use of locale dependent functions (bitcoin#13041)
  * 2018: Continuous testing of format strings (bitcoin#13705)
  * 2018: Continuous compilation with MSVC `TreatWarningAsError` (bitcoin#14151)
  * 2018: Continuous testing under UndefinedBehaviorSanitizer – UBSan (bitcoin#14252, bitcoin#14673, bitcoin#17006)
  * 2018: Continuous testing under AddressSanitizer – ASan (bitcoin#14794, bitcoin#17205, bitcoin#17674)
  * 2018: Continuous testing under ThreadSanitizer – TSan (bitcoin#14829)
  * 2019: Continuous testing in an unsigned char environment (`-funsigned-char`) (bitcoin#15134)
  * 2019: Continuous compile-time testing of assumptions we're making (bitcoin#15391)
  * 2019: Continuous testing of fuzz test cases under Valgrind (bitcoin#17633, bitcoin#18159, bitcoin#18166)
  * 2020: Finally... MemorySanitizer – MSAN! :)

  What is the next step? What tools should we add to CI to keep bugs from entering `master`? :)

ACKs for top commit:
  MarcoFalke:
    ACK 870f0cd

Tree-SHA512: 38327c8b75679d97d469fe42e704cacd1217447a5a603701dd8a58ee50b3be2c10248f8d68a479ed081c0c4b254589d3081c9183f991640b06ef689061f75578