C’s Biggest Mistake (2009)
digitalmars.com
C’s Biggest Mistake (2009)
1–10 of 382 posts
Re: C’s Biggest Mistake (2009)
#2I don't think it is a mistake in language design. In the 90s, memory was a rare good, and it still is in the microprocessor world, where "only" a few kilobytes of RAM are available. There are performance critical paths where passing a size_t is just unnecessary.
The actual mistake is to don't pass size_t as a user. This is one kind of "premature optimization". We can safely say the language design doesn't encourage the user to write safe code, and succeror languages do that.
Don't get me wrong — I just try to do the point that C itself is not the point to blame. It's people using computers who write the million dollar bugs.
Re: C’s Biggest Mistake (2009)
#3I don't think it is a mistake in language design. In the 90s, memory was a rare good, and it still is in the microprocessor world, where "only" a few kilobytes of RAM are available. There are performance critical paths where passing a size_t is just unnecessary. The actual mistake is to don't pass size_t as a user. This is one kind of "premature optimization". We can safely say the language design doesn't encourage t…
> There are performance critical paths where passing a size_t is just unnecessary
You would still be able to declare your function as taking a pointer (instead of an array, which in this world would be a far pointer) if you need to
He's saying to deprecate char[] as a parameter type, not char
Re: C’s Biggest Mistake (2009)
#4I don't think it is a mistake in language design. In the 90s, memory was a rare good, and it still is in the microprocessor world, where "only" a few kilobytes of RAM are available. There are performance critical paths where passing a size_t is just unnecessary. The actual mistake is to don't pass size_t as a user. This is one kind of "premature optimization". We can safely say the language design doesn't encourage t…
> There are performance critical paths where passing a size_t is just unnecessary You would still be able to declare your function as taking a pointer (instead of an array, which in this world would be a far pointer) if you need to He's saying to deprecate char[] as a parameter type, not char
That's right, nothing is taken away from the user with my proposal.
Re: C’s Biggest Mistake (2009)
#5The biggest mistake to me feels like implicit integer conversions. That's where C feels like it's really out to get you.
Re: C’s Biggest Mistake (2009)
#6I don't think it is a mistake in language design. In the 90s, memory was a rare good, and it still is in the microprocessor world, where "only" a few kilobytes of RAM are available. There are performance critical paths where passing a size_t is just unnecessary. The actual mistake is to don't pass size_t as a user. This is one kind of "premature optimization". We can safely say the language design doesn't encourage t…
> There are performance critical paths where passing a size_t is just unnecessary You would still be able to declare your function as taking a pointer (instead of an array, which in this world would be a far pointer) if you need to He's saying to deprecate char[] as a parameter type, not char
An existing alternative is to put an array in a struct:
struct string123 {
char data[123];
};
Re: C’s Biggest Mistake (2009)
#7I don't think it is a mistake in language design. In the 90s, memory was a rare good, and it still is in the microprocessor world, where "only" a few kilobytes of RAM are available. There are performance critical paths where passing a size_t is just unnecessary. The actual mistake is to don't pass size_t as a user. This is one kind of "premature optimization". We can safely say the language design doesn't encourage t…
The #1 undetected bug problem with C programs is buffer overflows. Experience shows it is extremely difficult to verify that arbitrary C code doesn't have buffer overflows in it. Assistance from the core language design can improve things a great deal.
D allows passing both raw pointers as parameters and pointer/length pairs. It's up to the user to choose. In practice, people have simply moved away from using raw pointers into buffers.
As for performance, in C to determine the length of a string one uses strlen(). Over and over and over again on the same string. This can be a major performance problem, even not considering the memory cache effects. When I look at speeding up C code, often the first nuggets of gold is reviewing all the explicit and implicit uses of strlen(). (Implicit uses are functions like strcat()). It's also the first place I look for bugs when reviewing C code - anytime you see a sequence of strlen, strcat, strcpy, it's often broken (typically in neglecting somewhere to account for the extra 0 byte).
Re: C’s Biggest Mistake (2009)
#8Re: C’s Biggest Mistake (2009)
#9> Conflating pointers with arrays.
AND Strings.
FTFY.
Re: C’s Biggest Mistake (2009)
#10The biggest mistake to me feels like implicit integer conversions. That's where C feels like it's really out to get you.
Agree. And they have leaked out to C++ where they have been very hard to fix, and even, to some degree, to Rust.