C++ is not a superset of C

Very 1995, no offense.

In other news, 1+1=2; and two wrongs don't make a right (but three lefts do.)

> The size of the array needs to be known at compile time. In C++, a const variable can be a constant expression, meaning it can be evaluated at compile time. In C, this is not the case, and we must instead use a pre-processor macro:

Enums are also good here in C land for specifying compile time constants.

> I'm suspicious of restrict. It seems like playing with fire, and anecdotally it seems common to run into compiler optimisation bugs when using it because it's exercised so little.

On the contrary, I wish C++ had restrict in the standard, for exactly the reasons mentioned: it can help the optimizer in certain cases.

Several of the examples shown as valid C are not.

For example, this:

    const int foo = 1;
    int* bar = &foo;
    *bar = 2;

is said to have undefined behavior, but in fact the initialization of `bar` is a constraint violation, requiring a diagnostic. (Some compilers will issue a non-fatal warning, which is allowed by the C standard but IMHO is unfortunate.)

Another example: it says that this:

    const size_t buffer_size = 5;
    int buffer[buffer_size];

will not compile in C, but it's valid at block scope in C99, which introduced variable-length arrays. (C11 made them optional.)

"In C, this would compile, albeit likely with warnings about implicit conversion:"

    int main() {
        auto x = "actually an int";
        return x;
    }

The "implicit int" rule was dropped in C99, and even before that the language did not define an implicit conversion from char* to int. Again, some compilers might support it with a warning, but it's a constraint violation.