Live data from Hacker News

C’s Biggest Mistake (2009)

digitalmars.com

241–250 of 382 posts

Re: C’s Biggest Mistake (2009)

#241
The proposed change has another important aspect to it: it would help standardize a way of passing arrays across language boundaries. Currently when using FFI, you often have to decompose fat pointers into pointer and length before calling a foreign function, or compose a fat pointer from a pointer and length in extern functions. This could mean languages like rust, d, etc. Could just pass arrays directly.

I for one would love to see this proposal become a reality.

Re: C’s Biggest Mistake (2009)

#242
That is "modern" C++ is frequently being used as "C with classes and basic safety".

I 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)

#243
post #142

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

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)

#244

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

Do you think there are good contenders to replace C? V seems like it could.

Re: C’s Biggest Mistake (2009)

#245

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

I would wager the percentage of embedded projects than are picking C has decreased in the past 10 years. I have no direct evidence of that, but I think it's a likely guess.

Re: C’s Biggest Mistake (2009)

#246

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

Well, it could also solve the problem of sizeof(array) not working inside the function.

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)

#247
post #183

Earlier quoted context omitted.

Thank you for enforcing arguments of authority.

There's "arguments of authority" and then there's "accusing Walter Bright of having never written a line of code before".

AKA: Conflating authority with expertise

Re: C’s Biggest Mistake (2009)

#248

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

> Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.

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)

#249
post #229
post #156

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

[[citation needed]]
Post reply on HN