Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Null References: The Billion Dollar Mistake (2009) [video]

infoq.com

Post reply on HN
Print view View original

21–30 of 130 posts

Re: Null References: The Billion Dollar Mistake (2009) [video]

#21

Post by slaymaker1907 »

WalterBright wrote: post #3

Nah. The billion dollar mistake is actually C arrays decaying to pointers, enabling buffer overflows, the #1 cause of bugs and malware injection in shipped C programs. https://www.digitalmars.com/articles/C-biggest-mistake.html It's simple to fix this in C, too.

I don't think it's quite so simple to fix since you still need to decide when to actually check the size vs. when it is safe to omit. While branch predictors are great, you can end up having so many potential branches that it starts to lose effectiveness. In practice, I rarely see anything besides strings that lack the size variable, it's just that the bounds may not be checked.

Null terminated strings were a horrible mistake though and really should have been fat pointers.

Re: Null References: The Billion Dollar Mistake (2009) [video]

#22

Post by josephg »

itronitron wrote: post #15
petilon wrote: post #7

If null references are a mistake, isn't initializing an array index variable to -1 a mistake too?

Yes, I suppose null references are only a problem if you are unable to write a conditional statement.

The problem with null references is you have to write those conditional statements everywhere, otherwise your program might crash. You generally know as the programmer which pointers you expect to be nullable and which should always be an object. But the compiler has no idea, so it can’t help make sure you have null checks in all the places you need them.

Re: Null References: The Billion Dollar Mistake (2009) [video]

#23

Post by Arch-TK »

marcodiego wrote: post #11
WalterBright wrote: post #3

Nah. The billion dollar mistake is actually C arrays decaying to pointers, enabling buffer overflows, the #1 cause of bugs and malware injection in shipped C programs. https://www.digitalmars.com/articles/C-biggest-mistake.html It's simple to fix this in C, too.

Genuinely curious: why don't suggest that to WG14? (WG14) is the ISO workgroup which maintains the C specification.

And what would it achieve to "fix" this (without re-designing the rest of the language)?

Every piece of code such as:

    int a[SIZE];
    foo(a, SIZE);
Would have to be rewritten to:

    int a[SIZE];
    foo(&a[0], SIZE);
And this additional noise would just make C harder to write for no reason. Rather than making C harder to write, just pick a different programming language.

Re: Null References: The Billion Dollar Mistake (2009) [video]

#24

Post by xjay »

WalterBright wrote: post #3

Nah. The billion dollar mistake is actually C arrays decaying to pointers, enabling buffer overflows, the #1 cause of bugs and malware injection in shipped C programs. https://www.digitalmars.com/articles/C-biggest-mistake.html It's simple to fix this in C, too.

Not to forget that classic increment of a signed integer waiting to overflow and trigger an exception on some critical (unpatched) hard disk drive controller out there..

  ++countdown;

Re: Null References: The Billion Dollar Mistake (2009) [video]

#25

Post by Arch-TK »

revskill wrote: post #13

The compiler should check for null reference before deferencing here.

At the cost of basically all performance or incredible compiler complexity.

A better solution: Implement a different language with a better type system instead. Or pick one of the hundreds that already exist and can represent the concept of a tagged union without having to implement it manually.

Re: Null References: The Billion Dollar Mistake (2009) [video]

#26

Post by asguy »

LanceH wrote: post #5
WalterBright wrote: post #3

Nah. The billion dollar mistake is actually C arrays decaying to pointers, enabling buffer overflows, the #1 cause of bugs and malware injection in shipped C programs. https://www.digitalmars.com/articles/C-biggest-mistake.html It's simple to fix this in C, too.

Which would all be a rounding area if C gets to take credit for everything produced using it.

This is what C/C++ haters, anti x86/amd64 snobs, and Rust elitists always forget: what works, works. Sure, it could be a local maximum, hopefully there will be better, but who knows?

To quote Sean Connery in The Rock:

Losers always whine about their best. Winners go home and fuck the prom queen!

https://m.youtube.com/watch?v=gXDSxgDUv-c

Re: Null References: The Billion Dollar Mistake (2009) [video]

#27

Post by WalterBright »

nicoburns wrote: post #12
WalterBright wrote: post #3

Nah. The billion dollar mistake is actually C arrays decaying to pointers, enabling buffer overflows, the #1 cause of bugs and malware injection in shipped C programs. https://www.digitalmars.com/articles/C-biggest-mistake.html It's simple to fix this in C, too.

They're probably BOTH quite literally billion dollars mistakes.

I remember the bad old DOS days where a null pointer write would scramble DOS. I absolutely hated that, and it cost me a lot of extra work. Enter protected mode programming. It was a miracle! Null pointer writes now meant a seg fault with a traceback, and voila! A few minutes of fix and I'm on my way. I immediately switched all my dev work to a protected mode system, and ported to real mode only as a last step.

Buffer overflows are the primary entry point for malware. Seg faults are not. Hence the former are far more costly.

Re: Null References: The Billion Dollar Mistake (2009) [video]

#28

Post by WalterBright »

josephg wrote: post #17
mjevans wrote: post #9

Earlier quoted context omitted.

I think golang's slices are a better solution than the linked article. https://go.dev/ref/spec#Slice_types Slices can still be nil (null), but it isn't an unsafe memory access operation, just another type of potentially useful or potentially errant invocation to handle.

Zig and Rust also support array slices. But they can’t be null, because that’s - as the article says - a mistake. https://ziglang.org/documentation/master/#Slices https://doc.rust-lang.org/book/ch04-03-slices.html

D slices can be null, but they're not a mistake, as the runtime will not let you read/write a 0 length array.

Re: Null References: The Billion Dollar Mistake (2009) [video]

#29

Post by GuB-42 »

dpkirchner wrote: post #8
WalterBright wrote: post #3

Nah. The billion dollar mistake is actually C arrays decaying to pointers, enabling buffer overflows, the #1 cause of bugs and malware injection in shipped C programs. https://www.digitalmars.com/articles/C-biggest-mistake.html It's simple to fix this in C, too.

We could go further: the billion dollar mistake was allowing values intended to be used as data to be executed (pre-NX bit). Zero-terminated C strings is up there as well.

The code vs data distinction is a hardware thing, this is not about C. More precisely, it is the difference between a Harvard and a Von Neumann architecture. A Harvard architecture has completely separate paths between instructions and data: different buses, different memories. A Von Neumann architecture has common instruction and data paths, and therefore, naturally, data is executable. You can write C code for both.

Modern PC-style hardware is kind of a hybrid, acts like Harvard with regard to cache, and like Von Neumann with regard to RAM. Furthermore, it has a fancy MMU that allows for things like the NX bit. All C compilers/linkers I am aware of know the difference between code and data and are able to put each one in the appropriate section, what is done after that is the OS/hardware responsibility.

As for zero-terminated strings, I also think it is mostly a mistake, though it does have a few advantages. You can still work with size+pointer though, using mem- instead of the str- functions, and "%.*s" in printf(), not ideal though.

Re: Null References: The Billion Dollar Mistake (2009) [video]

#30

Post by WalterBright »

Arch-TK wrote: post #23
marcodiego wrote: post #11

Earlier quoted context omitted.

Genuinely curious: why don't suggest that to WG14? (WG14) is the ISO workgroup which maintains the C specification.

And what would it achieve to "fix" this (without re-designing the rest of the language)? Every piece of code such as: int a[SIZE]; foo(a, SIZE); Would have to be rewritten to: int a[SIZE]; foo(&a[0], SIZE); And this additional noise would just make C harder to write for no reason. Rather than making C harder to write, just pick a different programming language.

The article I referenced says how this is fixed. It is not harder to write at all.
Post reply on HN