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

41–50 of 130 posts

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

#41

Post by kaba0 »

Arch-TK wrote: post #25
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.

I am absolutely in favor of languages that exclude nulls from their type systems, bur your first point is a very simplictic take.

Null pointer checks are very, very cheap, no additional memory fetch since the pointer value is needed either way, easy to predict the slow path and if we are talking about languages that can deoptimize, then it is literally free (checked by hardware either way) -> a null value will cause a segfault, which will deoptimize the code on the slow path and continue from there. So it is not a problem from a performance point of view.

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

#42

Post by kristoff_it »

mjevans wrote: post #9
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 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.

Go's slices are more akin to ArrayLists / Vectors in other languages, since they also manage the underlying buffer.

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

#43

Post by pjmlp »

asguy wrote: post #38
pjmlp wrote: post #35

Earlier quoted context omitted.

Some of us are old enough to be coding when C was only relevant for university departments privileged to have UNIX boxes. So we know there are other ways, we used systems with zero lines of C into them. The prom queen came naked offering herself to everyone and the party was done for the other folks.

That excuse sounds like the guy in highschool who would have treated the girl so much better, but she was into assholes. If you are old enough to remember those days, then you remember COBOL, Algol, Fortran, Pascal, BASIC, Ada, Oberon, Lisp/Scheme, Forth, O’Caml etc. They’re all great languages, some still have their uses. There’s a reason all of the major operating systems have cores written in C/C++. It’s entirely…

The power of free beer with source tapes is very mighty.

Thankfully governments have finally start paying attention regarding software liability.

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

#44

Post by renox »

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.

While I agree with you. It's still infuriating that these (serious) flaws in C apparently can't be fixed/evolved inside the language and that instead you have to use a different language instead..

That's throwing the baby with the bathwater :-(

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

#46

Post by dang »

vippy wrote: post #6

[flagged]

Could you please stop posting unsubstantive comments? You've unfortunately done that repeatedly, and we're trying for something else here.

Fortunately you've also posted good comments, so this should be easy to fix.

If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html and taking the intended spirit of the site more to heart, we'd be grateful.

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

#47

Post by dang »

Related:

Tony Hoare's Null References: The Billion Dollar Mistake - https://news.ycombinator.com/item?id=30719472 - March 2022 (13 comments)

Null References: The Billion Dollar Mistake - https://news.ycombinator.com/item?id=22019627 - Jan 2020 (150 comments)

Null References: The Billion Dollar Mistake – Tony Hoare (2009) [video] - https://news.ycombinator.com/item?id=11798518 - May 2016 (79 comments)

Tony Hoare / Historically Bad Ideas: "Null References: The Billion Dollar Mistake" - https://news.ycombinator.com/item?id=473158 - Feb 2009 (2 comments)

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

#48

Post by renox »

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.

> Zero-terminated C strings is up there as well.

I disagree here, remember that at the time some strings with length implementations used only one or two bytes for the length, this can creates lots of issues that zero terminated strings don't have.

Of course nowadays zero terminated strings don't make sense anymore.

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

#49

Post by unxdfa »

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 can confirm I have fucked up on numerous occasions which resulted in NPEs which caused business processes to fail spectacularly and write off millions of dollars instantly. Fortunately in every case it was possible to recover, replay or repair the data so the only real cost was a little bit of reputation and time and money. But that adds up across tens of thousands of engineers, probably to billions by now globally.

I learned a lot from this and discovered that the real issue is that a process can fail spectacularly and do any damage at all. There are so many other concerns other than NPEs which need to be considered.

Post reply on HN