Not sure if the parent comment was edited or not, but at the time I'm reading it, it just says "typed", not "strongly typed". Strong versus weak typing isn't something I've seen a consistent definition of that everyone agrees on (although most definitions I've seen would consider C to be somewhat weakly typed because generally almost any type can be coerced to any other type without much ability to tell if the result is valid or not), but statically versus dynamically typed is pretty well defined, and C certainly is a statically typed language.
My point is that it's not typed stongly enough to make certain kinds of static code analysis easily doable. It is totally possible to encounter a type mismatch at runtime because the compiler didn't complain (because the code is technically valid?). There are languages where this is much different, e.g. Java.
It's definitely possible to encounter a type error at runtime in Java due to the compiler not checking certain things. Java allowing subclasses across arrays is somewhat notorious for this sort of pitfall; in the classic example of `Dog` and `Cat` being subclasses of `Animal` (or implementations of the `Animal` interface; the issue is the same either way), Java will let you declare an array of type `Animal` but assign an array of `Dog` to the variable, which then will throw an error only at runtime if you try to put a `Cat` in the array:
interface Animal {}
class Cat implements Animal {}
class Dog implements Animal {}
Animal[] animals = new Dog[1];
animals[0] = new Cat(); // This will throw an error at runtime
If I'm remembering correctly, the property of not throwing type errors at runtime due to things that could be caught at compile time is called "soundness", which like static versus dynamic typing is much more formally defined than strong versus weak typing. I definitely agree that C has a lot of pitfalls in this regard, but I think you might be surprised how many mainstream "strongly typed" languages have these sort of issues.
