I think this presentation is interesting from a programming language design point of view; if you were designing a new language, this presentation highlights various 'gotchas' in C and C++ that might be the sort of thing you would try to avoid creating in your new language.
Many of these fall under the heading of opportunities to apply the Pythonic design criterion "refuse the temptation to guess":
1) in C, according to one of the comments, it was claimed (i didn't check) that if you declare your own printf with the wrong signature, it will still be linked to the printf in the std library, but will crash at runtime, e.g. "void printf( int x, int y); main() {int a=42, b=99; printf( a, b);}" will apparently crash.
-- A new programming language might want to throw a compile-time error in such a case (as C++ apparently does, according to the slides).
2) In C, depending on compiler options, you can read from an uninitialized variable without a warning
-- A new programming language might want to not auto-initialize any variables, and to throw a compile-time error if they are used before initialization.
3) In C, code like "int a = 41; a = a++" apparently compiles but leaves 'a' in an undefined state because "you can only update a variable once between sequence points" or it becomes undefined, but on many compilers works anyway. A sequence point is "a point in the program's execution sequence where all previous side effects SHALL have taken place and all subsequent side-effects SHALL NOT have taken place".
-- A new programming language might want to throw a compile-time error in such a case
4) In C, the evaluation order of expressions is unspecified. so code like "a = b() + c()" can call b() and c() in any order. If they have side effects then this might matter, yet no compiler error is given. However, the evaluation order of a() && b() IS specified.
-- A new programming language might want to throw a compile-time error when side-effectful code is called in context in which the order of evaluation is unspecified.
Other miscellaneous gotchas:
5) In C, static vars (but not other vars) are initialized to 0 by default.
-- A new programming language might want to either auto-initialize all variables, or to not auto-initialize any variables,
6) The presentation says "C has very few sequence points. This helps to maximize optimization opportunities for the compiler.". This is a tradeoff between optimization vs. principal of least surprise.
-- A new programming language which wanted to make things as simple as possible would maximize 'sequence points', putting them in between practically every computation step. But some new programming languages would choose to minimize sequence points in order to allow the compiler to optimize as much as possible.
7) The presentation says that the standard says that source code must end with a newline.
-- Imo that's a bit pedantic and the ideal programming language would not care if code ended in a newline.
8) In one context (inside a function), the 'static' keyword is used to make a variable persist across calls to that function. But in another context (outside of any function), the same 'static' keyword is used as an access modifier to define visibility to other compilation units!
-- Using the same keyword for two different (albeit related) purposes is confusing. A new programming language might either drop one of those features entirely, or have a distinct keyword for it.