Yes, those are the three I am referring to, but I don't agree that any are generous or dubious. Out of the C context, what does "not integer" possibly mean? `i` should either have been a boolean, or apparently an explicit multi-state enum, rather than the ever-favored weakly-typed ubiquitous `int` that C makes so attractive.

I'm not claiming the unused parameter bug, because there can be legitimate unused function parameters, and we can easily envision a very similar bug that still used all parameters.

But add in the current Apple bug that precipitated this post, and you have 4/6.

The general defense by C programmers is that everything works as long as you do the right thing. I have been there. However as these bugs illustrate, vigilance does not scale.

C has enums, and it's true that they can be implicitly used as ints and sometimes that can be bad, but here they just weren't used. I'm not sure what you think C could have done differently. It's not obvious to me that the current enums aren't good enough for this particular purpose, for example. This feels more like a culture thing than a language thing.

And note that 2/3 of the bugs you're claiming, apply to all weakly typed languages, of which there are many. Python would not have prevented them, for example. Showcasing them as problems with C seems somehow fishy. (I don't mean to imply dubious motivations on your part, I just get the feeling of "there's something not quite right with this argument".)

A lot of it is culture, but I feel that culture fuels itself with the tricks available in the language. It just feels so clever to use the return value of `i++` - number of lines matters one-level down in ASM, so why not here. And things like `if (!i)` are quite cute, while being hard to aggregate unions of existing types, so return-value definitions especially tend to stay informal.

You're right about my analysis applying to all weakly typed languages, or at least languages with weakly-typed core functions. Python pretty much only brings memory safety to the table (which as I said in a sibling comment has an actual overhead so I didn't touch upon it here). But it does show that the Tarsnap and the Apple bug are caused by syntax, which is a pretty heavy indictment.

Python is a strongly typed language.

For every language, there are senses in which it is strongly typed and others in which it is weakly typed.

In this case, we're referring to none of these being errors as weak typing:

    if 0: pass
    not 42
    'a' == 9

> The compiler could have prevented 'X' by not permitting "function == int" comparisons. That's 1/5.

0 is also a special case litteral for the null pointer, and function names are valid in pointer contexts, so I'm not even sure that "f == 0" is badly typed.

Only in C++ pre C++11 - most C compilers use

#define NULL ((void *)0)

in which case, using NULL, you're comparing a function to a pointer.