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

51–60 of 130 posts

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

#51

Post by WalterBright »

pjmlp wrote: post #43
asguy wrote: post #38

Earlier quoted context omitted.

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.

> Thankfully governments have finally start paying attention regarding software liability.

And we'll see a great slowdown in the software industry.

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

#52

Post by pjmlp »

WalterBright wrote: post #51
pjmlp wrote: post #43

Earlier quoted context omitted.

The power of free beer with source tapes is very mighty. Thankfully governments have finally start paying attention regarding software liability.

> Thankfully governments have finally start paying attention regarding software liability. And we'll see a great slowdown in the software industry.

When people buy damaged goods, they ask for a refund, they don't expect to close and reopen the box and have the product reappear in perfect shape.

The industry has miseducated them, and now it is finally happening, software products aren't a special snowflake.

Digital stores with returns, consulting contracts with warranty clauses with fixes at the expense of provider, and naturally cyber security bills.

Move fast and break things only works due to lack of liability.

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

#53

Post by Arch-TK »

WalterBright wrote: post #31
Arch-TK wrote: post #19

Earlier quoted context omitted.

Nothing is decaying. It is an implicit conversion. To say something "decays" implies something else is lost, the array is still there.

Something is lost - the array length. "Decays" is the correct word.

It is not correct. The array length is still there, what is happening is that you are implicitly asking for only a pointer to the first element of the array because of the context in which it is used. You did not ask for its length. The language has no way of passing an array itself by value. You could have asked for a pointer to the whole array but you didn't. When you are using an array in the context in which it is not an operand of the sizeof operator, the unary & operator, and not as a string literal used to initialise an array, then the expression which forms the use of the array involves an implicit conversion which produces a pointer to its first element.

You might think it's pedantic, but we're talking about C, it is important to be clear in language used to talk about C as it's an unforgiving language.

There is an untold amount of confusion surrounding how arrays work in C at least in part because of silly wording like "decay".

As a final note: When you write "f(foo.bar)" to call "f" while referring only to the "bar" field of the struct "foo" you are not losing "foo" and it is not "decaying" solely because the function which receives the result of the expression which formed the first argument of its invocation only sees the "bar" field of "foo". And now I'm not saying that it's a conversion either, but the point still stands. If "f(a)" where "a" is an array involves decay then so does array indexing or accessing a struct field.

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

#54

Post by mariosisters »

asguy wrote: post #26
LanceH wrote: post #5

Earlier quoted context omitted.

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

Nailed it with this quote, especially because it scales to all levels of product development. Literally the only thing that matters (in the context of business success, of course) is if it works enough to keep going up and the the right.

No one cares about your code.

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

#55

Post by Arch-TK »

WalterBright wrote: post #30
Arch-TK wrote: post #23

Earlier quoted context omitted.

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.

Adding fat pointers to C is a major redesign and the fact that the explanation fits within a short blog post doesn't make it an easy fix.

If you don't add fat pointers (thereby requiring a major re-design of the language and causing an endless amount of pain with regards to ABIs etc) then the solution, which involves removing the implicit conversion of an array to a pointer to its first element in expressions where it is not used as an operand of the sizeof operator, unary & operator or as a string literal used to initialise an array, certainly DOES make it harder to write C.

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

#56

Post by saagarjha »

pjmlp wrote: post #35
asguy wrote: post #26

Earlier quoted context omitted.

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

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.

I don't think this analogy needs continuing.

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

#57

Post by im3w1l »

WalterBright wrote: post #51
pjmlp wrote: post #43

Earlier quoted context omitted.

The power of free beer with source tapes is very mighty. Thankfully governments have finally start paying attention regarding software liability.

> Thankfully governments have finally start paying attention regarding software liability. And we'll see a great slowdown in the software industry.

For every year the industry becomes more mature. And with maturity comes less need for speedy innovation, and higher need for quality and reliability. It may happen in five years or in twenty, but it seems almost certain that it must happen.

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

#58

Post by imoverclocked »

unxdfa wrote: post #49
nicoburns wrote: post #12

Earlier quoted context omitted.

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…

> There are so many other concerns other than NPEs which need to be considered.

Yes. However, not all of those are trivially avoidable by just slightly changing the tech underneath.

I chose a battle with NPEs in a giant Java codebase and largely won. It wasn't trivial to do but the main take-away is that in order for Java to be backward compatible, javac can't enforce any mechanism to make a codebase consistent enough to be NPE free. One way to get this consistency is to change the semantics slightly to trace nulls accurately (some JVM languages attempt this and fail with 3rd party dependencies for eg) and enforce that you can't write code that will produce an NPE. There is even an errorprone plugin that does a pretty good (though not perfect) job of this called NullAway. For codebases that think they can do better and that "need" more flexibility in null handling, there are other frameworks. I'm hard-pressed to meet that need outside of legacy/untouchable code constraints.

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

#59

Post by saagarjha »

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.

Car crashes are also a rounding error compared to the number of people who get to their destination safely. There's substantial investment in both vehicular safety and program analysis to improve both.

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

#60

Post by noogle »

pjmlp wrote: post #32

Besides the approach taken by some FP languages, others like Eiffel already fixed it in the 1990's, while having nullable types, by making it a compiler error to access reference types without checking for null, unless the types are declared a non nullable. So it just took some time to get mainstream.

Sounds similar to Kotlin's and TypeScript's approach.

The basic issue exists - how to handle unknown values. It goes beyond programming language constructs.

Post reply on HN