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

81–90 of 130 posts

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

#81

Post by WalterBright »

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…

> The array length is still there

If it was, we wouldn't be having this discussion and array bounds checking would have been added to C compilers 40 years ago.

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

#82

Post by kilgnad »

HWR_14 wrote: post #75
kilgnad wrote: post #67

Earlier quoted context omitted.

The prom queen fucked the only thing that was available. Nowadays the prom queen has tinder, loads of competing options and is woke.

Unless you went to a very small school, the prom queen always had lots of options. That's the point of the quote. Tinder is irrelevant. The winners are the people who eventually she chooses. As for "is woke", I have no idea how to read that point.

>Unless you went to a very small school, the prom queen always had lots of options.

No, C was really the only available systems options. C and C++.

>Tinder is irrelevant. The winners are the people who eventually she chooses.

In the dating market today, tinder has created essentially a shit show for males. With that much choice and selection female hypegamy becomes expressed to the max. The top 80% of the top females match with the top 20% of males; It has never been this way for most of humanity. Even the top female always had a limited pool to choose from and her feelings would naturally calibrate to that fact. With tinder everything changed. You get the top tier males having a lot of fun and never settling down, while the rest just give up. That's hook up culture for you.

C would NEVER have been chosen if there were more options.

>As for "is woke", I have no idea how to read that point.

It's the same thing. Wokeness is the result of more womens' rights. Historically, all women couldn't be as selective as they are now because they couldn't hunt for food or work corporate jobs. Survival depended on them finding a man. This is no longer the case and is responsible for much greater female selectivity.

Again C succeeded because of very few alternative options and necessity.

Anyway I can see why you or other people missed the analogy. You have to be familiar with the modern dating game AND familiar with what programming was like 20-30 years ago. Most people capable of even making the comparison have been out of the game for ages.

The state of programming languages that are chosen today is very very much like the hookup culture of today. Especially on the front end, the front end is a woke prom queen for sure.

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

#83

Post by lmm »

AnimalMuppet wrote: post #74
lmm wrote: post #71

Earlier quoted context omitted.

Use some kind of range type, or, better, a type that represents "index into this array" (which needs some form of dependent typing, but is very much doable).

A range type has the problem that it's not necessarily valid indexes for this array - it could be for some other array. "Index into this array" is, as you say, better (presumably it keeps a pointer or a reference or something to the array), but even that isn't bulletproof. Something like realloc could shrink the array but keep the same pointer, or the array could be deallocated and a new one allocated that happened t…

> "Index into this array" is, as you say, better (presumably it keeps a pointer or a reference or something to the array), but even that isn't bulletproof. Something like realloc could shrink the array but keep the same pointer, or the array could be deallocated and a new one allocated that happened to get the same address.

You can address that with some concept of lifetimes or ownership.

> What you really need is that the array keeps track of its own limits - something like std::vector or Java's ArrayList. But then you're back to the overhead of checking each access.

IME that's less good than having a dedicated type for "index into this array", even if the latter isn't perfect. A bounds-checked access using an offset from a different array might not be reading from uninitialized memory, but it's still overwhelmingly likely to be a programming bug.

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

#84

Post by [deleted] »

kilgnad wrote: post #82
HWR_14 wrote: post #75

Earlier quoted context omitted.

Unless you went to a very small school, the prom queen always had lots of options. That's the point of the quote. Tinder is irrelevant. The winners are the people who eventually she chooses. As for "is woke", I have no idea how to read that point.

>Unless you went to a very small school, the prom queen always had lots of options. No, C was really the only available systems options. C and C++. >Tinder is irrelevant. The winners are the people who eventually she chooses. In the dating market today, tinder has created essentially a shit show for males. With that much choice and selection female hypegamy becomes expressed to the max. The top 80% of the top females…

[deleted]

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

#85

Post by dzdt »

In older C and C++ code by convention the meaning of the pointer object was what we would now call Option(Pointer) : it can either be a valid pointer or can be null. Both are correct, and correct code should handle both cases.

The mistake was in not providing any language features to enforce or support that convention, or to communicate when the pointer is guaranteed to be valid vs when the null option needs to be handled.

Having an optional type as the language default is fine and sensible but could really have used aome language support to make it less of a footgun.

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

#86

Post by berjin »

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 think this was a mistake.

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

#87

Post by mariosisters »

rcoveson wrote: post #65
mariosisters wrote: post #54

Earlier quoted context omitted.

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.

> ...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.

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

#88

Post by _kst_ »

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.

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, but writing new code to use this new feature doesn't look difficult. (But converting all existing C code would take approximately forever.)

How does the function access the dimension? Is there a new syntax for extracting the length from a fat pointer, or do you just propose extending the semantics of `sizeof`?

Is there an existing C compiler that implements this?

A minor question: Given the above declaration, would

    char c = '?';
    foo(&c);
be valid, treating `c` as a single-element array?

Finally, a very minor point: `...` is already a valid punctuator. I can't think of any ambiguities that would be introduced by adding `..` as a new symbol, but that might be just my lack of imagination. (Note that gcc uses `...` in its case range extension.)

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

#89

Post by bitwize »

mariosisters wrote: post #54
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

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.

John Ousterhout put it like: Not working to working is the biggest performance improvement.

No misogyny needed.

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

#90

Post by tadfisher »

_kst_ wrote: post #88
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.

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[20].

Post reply on HN