C’s Biggest Mistake (2009) • Hacker News Board

Re: C’s Biggest Mistake (2009)

#161

Post by GuB-42 » Sun, Sep 13, 2020, 2:19 AM UTC

I don't see a mistake here, certainly not a "biggest mistake".

This is C, not C++. Keep it simple.

Here, the idea is that there is no special type for "pointer+size" (what the author proposes as an array). Ok, let's add one and see the implications.

- How do I get the size, the number of elements? A "sizeof" like operator?

- Can I resize the array? If yes, how? If no, why?

- What happens if I overflow? Undefined behavior?

- A memcpy-like would be an obvious function to implement, what happens if sizes differ?

- What is the relationship between static arrays (ex: int a[5]) and "pointer+size" arrays? Are these completely different types? Is there an implicit cast between the two?

- About casting, how can I go from a separate pointer and size to an array and vice versa? If it is possible at all.

- What if I do a bit of pointer magic to access the internal representation of the array? Probably undefined behavior.

It is much more complex than "just add array[..]", I expect more tradeoffs, more undefined behaviors (C wouldn't be C without them). Adding complexity to the language can actually make things worse.

As for zero-terminated strings, they have advantages and drawbacks. They are preferred by the C library, but you can do pointer+size if you want by using mem* instead of str* , or %.*s instead of %s in printf (not sure about this one).

Re: C’s Biggest Mistake (2009)

#162

Post by saagarjha » Sun, Sep 13, 2020, 2:31 AM UTC

diegocg wrote: post #112

johnisgood wrote: post #98

Earlier quoted context omitted.

One of the niceties of C is that I can get anything done pretty damn quickly, without anything getting in my way. The syntax is extremely simple, too, vs. Rust. Rust is close to Perl when it comes to syntax; full of symbols. Too implicit for me. I want to look at the code, and I want to understand what the heck is going on, even if it is written by someone else. I usually do, with C. Rust? Not so much, and believe me…

Young programmers seem to prefer learning Rust than C. Generational replacement will take care of making Rust prevalent, no matter what existing programmers think.

Do they? Or are they just told that they should be using Rust? Even putting aside outdated curriculum, Rust is a fairly involved language to teach to a new programmer.

Re: C’s Biggest Mistake (2009)

#163

Post by andi999 » Sun, Sep 13, 2020, 2:31 AM UTC

monetus wrote: post #150

sys_64738 wrote: post #149

I’ve been writing C code for 30 years. What I like about it is code from back then is pretty much similar to what you’d right today so there’s limited need to chase the train. Sure it has security issues but if you don things ‘right’ it’s still untouchable, imo. Most other languages are heavy and slow compared to C. A lot are not even backwardly compatible (python) or suffer from being kitchen sinks (C++). My own opi…

Have you ever tried nim?

Does nim have numpy/scipy/matplotliv equivalents?

Re: C’s Biggest Mistake (2009)

#164

Post by knaq » Sun, Sep 13, 2020, 2:31 AM UTC

WalterBright wrote: post #15

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 meat of the proposal:

"a pair consisting of a pointer to the start of the array, and a size_t of the array dimension"

No, that still doesn't fix the ABI. It's syntactic sugar. It is most definitely not passing an array.

Passing an array means exactly that, no more and no less. For example, suppose this is your array:

  double foo[100][100];

The size is 80000 bytes. That is exactly how much data needs to be copied onto the stack, no more and no less.

Getting the array dimensions is secondary. It would be nice to have them work. They could automatically get names. They could get size checks, so a function might declare itself compatible with a certain range of sizes. That's all a bonus, of much lower importance than the actual ability to pass an array.

The inability to pass an array impacts numerous other languages because they use the C ABI. If you can't put those 80000 bytes on the stack in C, then you can't do it in any language. The whole software ecosystem is thus impoverished.

Re: C’s Biggest Mistake (2009)

#165

Post by andi999 » Sun, Sep 13, 2020, 2:32 AM UTC

blogant wrote: post #34

baby wrote: post #17

Earlier quoted context omitted.

I don't see a future where C survives, not only because of memory corruption bugs (although that's a pretty big one), but also for usability: the lack of package manager, common build system, good documentation, good standard library, etc. are just too much to compete with any modern system language.

> lack of package manager, common build system, good documentation. This is where C is superior to virtually every other language. It has K&R to start with [1], a wealth of examples to progress from there, man pages, autotools, cmake, static and shared libraries. > good standard library. It should have hash tables at least, but it isn't bad. [1] Which is still the best language book ever written (yes, it has some ant…

So what are the antipatterns?

Re: C’s Biggest Mistake (2009)

#166

Post by xmprt » Sun, Sep 13, 2020, 2:33 AM UTC

konjin wrote: post #156

WalterBright wrote: post #59

Earlier quoted context omitted.

I suspect C has been steadily losing ground since I made it.

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?

Is the number of devices that C is running on a good metric? I think the number of developers or number of projects using C makes more sense to track. And then get the market share. If there are 10x more devices today than 10 years ago then I'd sure hope C was running on more devices but anything less than 10x means C is losing ground.

Re: C’s Biggest Mistake (2009)

#167

Post by saagarjha » Sun, Sep 13, 2020, 2:34 AM UTC

Koshkin wrote: post #66

WalterBright wrote: post #30

Earlier quoted context omitted.

In my experience with language design, a little bit of syntactic sugar can have transformative results. C's function prototypes, syntactic sugar added circa 1990, were transformative for C programming.

I wonder if a better idea (in principle) would be to have some kind of hardware implementation, sort of like a finer-grained memory segmentation.

This is likely coming in ARM soon. (And I'm hopeful it's not even soon™, or "it came but nobody used it" as has happened on x86.)

Re: C’s Biggest Mistake (2009)

#168

Post by xmprt » Sun, Sep 13, 2020, 2:34 AM UTC

leptons wrote: post #155

datman347 wrote: post #146

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.

Someone once said COBOL would disappear. C will still be used long after you and I and everyone here have returned to dust.

Try becoming a COBOL developer and see how that works for you. Likening C to COBOL isn't doing it any favors.

Re: C’s Biggest Mistake (2009)

#169

Post by ratww » Sun, Sep 13, 2020, 2:39 AM UTC

WalterBright wrote: post #159

ratww wrote: post #157

Earlier quoted context omitted.

A question: since your company also makes a C/C++ compiler (and the repo has very :), have you considered adding this addition to it, as an experimental feature, perhaps to demonstrate its usefulness to other developers and standard bodies? (Although, now that I think of it, D itself might serve the same purpose)

I don't see much point in it. I've proposed this change to C in front of several audiences, and it never received any traction. If you want to experiment with it, you can use DasBetterC, i.e. running the D compiler with the `-betterC` switch, which enables programs to be built requiring only the C Standard Library. Fair warning - once you get accustomed to DasBetterC, you're not likely to want to go back to C :-)

> If you want to experiment with it, you can use DasBetterC, i.e. running the D compiler with the `-betterC`

I've been meaning to experiment with DasBetterC for a while, and I have a project C I've been wanting to migrate to something with proper strings (it's an converter for some binary file formats, but now I want it to import some obscure text formats too). Maybe that's the push I needed :)

After 20 minutes and about 250 out of 2098 lines converted, the error messages are very good and give very nice hints about what to change, I must say I prefer them to Rust's verbose messages.

Re: C’s Biggest Mistake (2009)

#170

Post by brundolf » Sun, Sep 13, 2020, 2:43 AM UTC

knaq wrote: post #164

WalterBright wrote: post #15

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 meat of the proposal: "a pair consisting of a pointer to the start of the array, and a size_t of the array dimension" No, that still doesn't fix the ABI. It's syntactic sugar. It is most definitely not passing an array. Passing an array means exactly that, no more and no less. For example, suppose this is your array: double foo[100][100]; The size is 80000 bytes. That is exactly how much data needs to be copied o…

Are you non-jokingly suggesting copying the entire array to and from the stack each time, as an alternative to the OP's proposal (and as a default best-practice)?