Earlier quoted context omitted.
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 a…
A strong, competitive free market naturally selects what people value the most. Because there is no black and white - most decisions are tradeoffs between cost, difficulty, time, convenience, safety, functionality, and so on. Government regulations practically place an infinity price on selected characteristics. The result is less entrants in the market, less competition and naturally worse results across all paramet…
Null References: The Billion Dollar Mistake (2009) [video]
111–120 of 130 posts
Re: Null References: The Billion Dollar Mistake (2009) [video]
#112Golang 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…
Fast compilation could still be done with it.
It only impresses those that never used programming languages with modules during the 1990s.
Re: Null References: The Billion Dollar Mistake (2009) [video]
#113Earlier quoted context omitted.
Yes. Make illegal states unrepresentable.
The problem is that you don't always have a legal state, especially at object creation. If you forbid illegal states you end up with fake objects taking the place of non-existent real ones. (What's Find supposed to return if it's not there??) In most cases it's better to blow up when you try to work with a null than to mistakenly work with something that takes the place of a null. A null is easier to detect and thus…
Easily solved by making an error to read before write, several languages do it.
Re: Null References: The Billion Dollar Mistake (2009) [video]
#114Earlier quoted context omitted.
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…
When you're talking about a language which people treat like a portable assembly language, yes it IS expensive. It may be cheap from the point of view of a higher level language where literally every operation is already expensive, but from the point of view of C this would be a killer. You are talking about a language in which people work to reduce the number of indirections, fiddle about with struct layout to optim…
People think it is portable assembly language, without realising the world has moved on from K&R C.
Re: Null References: The Billion Dollar Mistake (2009) [video]
#115Earlier 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.
A tool to do this transformation would not be hard.
That's not the point though. You would still have the same underlying issue (no way to intrinsically tie the size of the memory addressable using a pointer to the pointer) and the disadvantage of code being less clear (are you actually passing the pointer to just one element, are you trying to pass a pointer to the beginning of the whole array?)
The key takeaway is that the implicit conversion from array to pointer to first element is not the problem with C. The problem with C is that it's a very limited language which would require a re-design (e.g. fat pointers and implicit range checks everywhere, which, while solving one problem, wouldn't really solve ALL or even most of the problems with pointers).
I think that, for its time, C was a decent improvement over assembly programming. I think that in the current day and age if you are writing C and use modern tooling as well as follow a set of good guidelines (as well as have the right mentality and don't ACTUALLY treat is as high level assembly) it is possible to write more or less safe C in small doses. For anything else I think the correct solution is not to ponder how to fix C, or pretend like there's just one problem with it, instead the solution is to use a better language.
Re: Null References: The Billion Dollar Mistake (2009) [video]
#116Earlier quoted context omitted.
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 i…
> Adding fat pointers to C is a major redesign No, it isn't. I implemented it in D, and know what is involved. I've written two C compilers, as well. > the fact that the explanation fits within a short blog post doesn't make it an easy fix. Correct, but since I've actually done it, I'm in a good position to say it is an easy fix.
D is not C, your experience writing compilers doesn't make this an easy fix. The problem is not the cost of implementing this (trivial) it is the cost to the nature of the C programming language. This will never get past the C WG and will cause massive disruption to how C is used these days.
The point is, it's an easy fix if you make a new language, it is a difficult fix if you want to call the end result C.
Re: Null References: The Billion Dollar Mistake (2009) [video]
#117Earlier quoted context omitted.
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.
Yes, but I don't see how this has anything to do with what I wrote.
Re: Null References: The Billion Dollar Mistake (2009) [video]
#118Earlier quoted context omitted.
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.
Can you explain then, when I write:
struct s {
int bar;
int baz;
} foo = {
.bar = 5,
.baz = 6,
};
f(foo.bar);
The fact the function does not receive the array size does not mean that decay has happened.
That being said, nothing I just wrote wasn't in the comment you replied to, so maybe explain what it is from that comment that you didn't understand about my argument for why "decay" is simply the wrong word for what is happening.
Also: This has nothing to do with array bounds checking.
Also: Given the nature of the C language, I would find it surprising if compilers 40 years ago would have implemented bounds checking irrespective of if the language started out with either fat pointers or some other way of carrying the size of a specific array around with a pointer to its first element.
Re: Null References: The Billion Dollar Mistake (2009) [video]
#119Earlier quoted context omitted.
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 length is there but you can't access it.
Okay, so you agree that the array hasn't decayed, disappeared or otherwise stopped existing and that the word "decay" is a poor choice to describe what is happening?
Re: Null References: The Billion Dollar Mistake (2009) [video]
#120Earlier 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[…
Arrays are already distinct types.
char c;
&c; // type is char*
char arr[20];
&arr; // type is char (*p)[20], pointer to array of 20 char
The problem with dropping implicit array-to-pointer conversion is that it would break most existing C code. It would be a great idea for a new language.
Suggested reading: Section 6 of the comp.lang.c FAQ, https://www.c-faq.com/>. The relationship between arrays and pointers in C is admittedly confusing; this is the best resource I know of for explaining it.