Fixing C's Biggest Mistake

[Timon Gehr]

On 12/30/22 21:27, Walter Bright wrote:
> On 12/29/2022 8:01 PM, Timon Gehr wrote:
>  > Even array bounds overflow exceptions would be better as compile-time 
> errors. If you don't consider that practical, that's fine, I guess it 
> will take a couple of decades before people accept that this is a good 
> idea,
> 
> The size of the array depends on the environment. I don't see how to do 
> that at compile time.
> ...

Well, it can be done in many cases. The point is it would be even 
better. I made this point because you said a null pointer segfault is 
like a bounds-checking failure. I agree.

>  > but it's certainly practical today for null dereferences.
> 
> Pattern matching inserts an explicit runtime check, rather than using 
> the hardware memory protection to do the check. All you get with pattern 
> matching is (probably) a better error message, and a slower program. You 
> still get a fatal error, if the pattern match arm for the null pointer 
> is fatal.
> ...

If the pattern match arm for the null pointer is fatal, maybe the 
reference should not have been typed as nullable in the first place, and 
no check should have been required at all. You seem to be reasoning from 
the position that the fatal runtime error was unavoidable. This is just 
not the case I care about at all.

> You can also get a better error message with a seg fault if you code a 
> trap for that error.
> 
> Isn't it great that the hardware provides runtime null checking for you 
> at zero cost?
> ...

I am saying A > B, you are saying B > C. I agree that B > C. I don't 
know what to tell you.

> If a seg fault resulted in memory corruption, then I agree with you. But 
> it doesn't, it's at zero cost, your program runs at full speed.
> ...

Errors manifesting in production that should have been caught 
immediately at compile time are not zero cost. Not even close.

E.g., see https://deepsource.io/blog/exponential-cost-of-fixing-bugs/

Sometimes, the original developer is not even around anymore and/or does 
not care to fix crashes. The cost to users can be very high, and at the 
very least it is embarrassing to the developer.

> P.S. in the bad old DOS days, a null pointer write would scramble DOS's 
> interrupt table, which had unpredictable and often terrible effects. 
> Fortunately, uP's have evolved since then into having hardware memory 
> protection, so that is no longer an issue. As soon as I got a machine 
> with memory protection, I switched all my development to that. Only as a 
> last step did I recompile it for DOS.
> 

So your point is that B > C, therefore you switched from C to B.

My point is that A > B, so I want to switch from B to A.

Unfortunately, there's some nontrivial cost to jumping ship and 
switching languages, so I am engaging in this kind of seemingly 
fruitless discussion instead.