I for one would love to see this proposal become a reality.
C’s Biggest Mistake (2009)
241–250 of 382 posts
Re: C’s Biggest Mistake (2009)
#242I wonder if a better C can be made by just stripping-down the bloated C++ and introducing the "unsafe" keyword for dangerous features like directly using arrays, etc.
Re: C’s Biggest Mistake (2009)
#243Earlier quoted context omitted.
It simply impossible for C to finish or vanish. It is one of the most tested and rock solid pillar in programming world. Developers already mastered how to handle the issues you mentioned in article. They are not such big to discard C.
I mean it in the sense of starting new development of a major new project with it. Of course, C will be around a very long time, like COBOL and FORTRAN.
Re: C’s Biggest Mistake (2009)
#244Author here. I'll be blunt and repeat a prediction I made 3 years ago or so: C is finished if it doesn't address the buffer overflow problem, and this proposal is a simple, easy, backwards compatible way to do it. It is simply too expensive to deal with buffer overflow bugs anymore. This one addition will revolutionize C programming like adding function prototypes did.
Re: C’s Biggest Mistake (2009)
#245Earlier quoted context omitted.
I mean it in the sense of starting new development of a major new project with it. Of course, C will be around a very long time, like COBOL and FORTRAN.
How many new embedded projects are picking non-C languages currently? I'm no fan, but C is a long way from dead.
Re: C’s Biggest Mistake (2009)
#246Author here. I'll be blunt and repeat a prediction I made 3 years ago or so: C is finished if it doesn't address the buffer overflow problem, and this proposal is a simple, easy, backwards compatible way to do it. It is simply too expensive to deal with buffer overflow bugs anymore. This one addition will revolutionize C programming like adding function prototypes did.
The proposal is just syntactic sugar for an size argument. It doean't add or solve anything really.
More specifically, at the moment, it evaluates to the size of the pointer itself, which is useless. On the other hand;
static void
foo(int a[..])
{
for (size_t i = 0; i
... would be very useful, as it's the same syntax you can already use inside the function where the array is declared, which makes refactoring code into separate functions easier, as you don't have to replace instances of sizeof with your new size_t parameter name.The only thing I'd like to see is compatibility with the static keyword; so that you can declare it as a sized-array but still indicate a compile-time minimum number of array elements. At the moment, in C99, this does not compile without serious diagnostics which would immediately highlight the problem:
#include
static void
foo(int a[static 4])
{
for (size_t i = 0; i Re: C’s Biggest Mistake (2009)
#247Re: C’s Biggest Mistake (2009)
#248Earlier quoted context omitted.
He never said explicitly, he was just making a general statement. Not that it matters whether he did or didn't, there's a lot of things wrong with C, it will most likely eventually disappear, but not for reasons outlined in this article. That's what he was saying.
Well, he dismissed Bright’s argument as a random pet peeve from people who haven’t written a line of code in C before, so yes, I do think he said it explicitly.
This is one of HN's comment guidelines. If you're not sure that someone is who you think they are, you can just ask, e.g.: "Hey, are you Walter Bright who did X and Y?"
Re: C’s Biggest Mistake (2009)
#249Earlier quoted context omitted.
It's been 11 years, and C is running on more hardware than it ever has before, viz every android device. By what measure would C be losing ground?
The pyrrhic victory, other than the Linux kernel, everything else is a mix of C++ and Java, with a native compiler written in C++. And the history of Linux kernel and Android might come to an end if Zirkon ever replaces it, then it will be no more C on Android.