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

91–100 of 130 posts

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

#91

Post by yakubin »

MichaelMoser123 wrote: post #69
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 didn't like to pass around the dimension of the array with the argument value. That got them a few bytes at the cost of a billion dollars. That's the same kind of trade off as with zero as end of string marker. On the other side: the platform might not have received any following without saving a few bytes here and there, computer memory was a scarce resource at the time.

That also means that making substrings requires both additional memory and time. Penny wise, dollar stupid. Not to mention the cycles wasted on recomputing strlen().

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

#92

Post by Patrickmi »

berjin wrote: post #86

Golang has to be the worst language for this problem considering it's young age. It was launched the same year at this post so it would have been a great opportunity back then to deal with the problem in a fresh language without needing to worry about compatibility constraints. It also doesn't have any ?. operator to elegantly deal with the problem. I know fast compilation and explicitness are the goals with go but I…

Hmmmm…..

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

#93

Post by tadfisher »

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.

null references are a problem when:

- null is a valid member of every type - there's no way to constrain a reference to only non-null members of the referenced type - the compiler allows dereferencing values of a nullable type

Weirdly, all three are true of C, C++ and Java.

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

#94

Post by erik_seaberg »

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

Earlier quoted context omitted.

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 i…

K&R C could only pass scalars, so structs were rejected while arrays became pointers. ANSI C didn’t dare change the legacy behavior when passing an array, but if you embed the array in a struct and pass that, it works correctly.

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

#95

Post by _8j50 »

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.

Hate to break it to you but buffer overflows don't need arrays, for stack at least, regardless of how arrays are constructed, the ability to predictably overwrite the saved IP is all you need.

X86 restricting saved IP read/write on the stack to special instructions like call or ret would have been nice (mark stack memory as restricted when call saves eip for example$

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

#96

Post by rcoveson »

mariosisters wrote: post #87
rcoveson wrote: post #65

Earlier quoted context omitted.

> ...is if it works enough to keep going up and the the right. Right, because that's a one-bit truth value, not a scalar. The slope doesn't matter, it just has to be positive. Everything is so simple! There's no such thing as high margins, or success in degrees. Is there something adding friction to the process of making software/food/cars? Well, is it adding enough friction to make our profits go negative? No? Then…

The one bit value of growing vs not is the primary determinant of success (in this industry), yes. I’m not making a lifestyle biz.

With your philosophy that literally reduces engineering to “does it make any profit at all true or false”, I would hope that you would confine yourself to the lifestyle industry.

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

#97

Post by pjmlp »

WalterBright wrote: post #77
im3w1l wrote: post #57

Earlier quoted context omitted.

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.

Software naturally grows more reliable every year. Government intervention won't improve things.

If we waited for the market to decide that car safety mattered, seatbelts still wouldn't be a thing, or helmets for driving motorcycles.

Occasionally the market isn't able to reach the optimal goal without some extra help.

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

#98

Post by tylerhou »

tadfisher wrote: post #90
_kst_ wrote: post #88

Earlier quoted context omitted.

Your proposed fix in [the article]( https://www.digitalmars.com/articles/C-biggest-mistake.html ) is to add a new function declaration syntax: void foo(char a[..]); that causes an array argument to be passed as a "fat pointer", consisting of a pointer to the initial element of the array plus a `size_t` value for the array dimension. Tentatively, I like the idea. As you acknowledge, this wouldn't fix existing code, bu…

I would go all-in and make arrays a distinct type , so the only way to create an array is with the [..] syntax, and forbid implicit type compatibility between arrays and pointers (which would discard the dimension part of the array type). An explicit conversion (cast) from pointer-to-array should require the dimension as part of the type. So &c on a char should produce char , and &c on a char[20] should produce char[…

Why not standardize something like std::span in C?

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

#99

Post by jbverschoor »

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 think a billion is heavily usually the impact

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

#100

Post by yarg »

We keep going on about this as if it's in any way different from every other situation where we've benefited significantly from an abstraction from the underlying machine.

But reflecting the underlying machine was not just a completely reasonable default it was the most viable performant option at the time.

And provided a clean enough means for writing cross platform compilers for more abstracted languages.

We probably took too long coming up with validated optionals as an abstraction, but so much is obvious in retrospect.

There is a lot that can be done, that must be done, but should only be done rarely - but the powers provided by a language that reflects the underlying machine are vital nonetheless.

You shouldn't be writing goto on a daily basis, but it's very useful for custom loop definitions.

Post reply on HN