Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C’s Biggest Mistake (2009)

digitalmars.com

Post reply on HN
Print view View original

221–230 of 382 posts

Re: C’s Biggest Mistake (2009)

#221

Post by zestyping »

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

I don't get why it hasn't gotten traction. When I read it, it was immediately obvious to me that this would be extremely helpful. I want it yesterday, and so should everyone.

Re: C’s Biggest Mistake (2009)

#222

Post by zestyping »

rightbyte wrote: post #24
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 proposal is just syntactic sugar for an size argument. It doean't add or solve anything really.

It is not just for the size argument. The array becomes an abstract data type whose bounds are consulted when the array is indexed. That's the key.

Yes, it's not a lot of effort to manually add a size_t argument. But it is far too tedious and error-prone to expect a programmer to add all the bounds checks. Being able to effortlessly tell the compiler "please check for me" is the huge win.

The second huge win is that the array is type-checked. So if you pass it to another function, the compiler enforces that it must again be passed with the size included. You don't get that by manually adding a size argument.

Re: C’s Biggest Mistake (2009)

#223

Post by souprock »

johnisgood wrote: post #184
saagarjha wrote: post #162

Earlier quoted context omitted.

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.

Indeed. What languages are most common in universities anyways? Haskell? Java? C++? OCaml? Which ones are the most common? Maybe he meant outside of the education system. I think the reason for that would be hype and peer pressure, and the feeling of novelty, with a hint of FOMO. I do not see any languages being pushed/hyped as hard as Rust.

I investigated this in Florida. I checked Florida Tech, Embry-Riddle, and a half dozen state universities. One was Java, two or three were C++ (really C with cout and maybe vector), and all the rest were plain C.

That is a mighty good showing for C.

Re: C’s Biggest Mistake (2009)

#224

Post by ScottBurson »

Yes. As I've long said, C does not have arrays. It has pointers and notations for initializing memory, but it does not have arrays.

There are actually two problems here. One is the absence of bounds checking. The other, which is related but technically orthogonal, is the hole in the type system: an array is not an object. It's been true since Unix v7 that you can pass or return a struct by value, but you can't pass an array by value unless you wrap it in a struct.

The type system also makes no distinction between a pointer to a single object and a pointer into an array of objects. I've worked on static analysis tools that try to find potential buffer overflows, and this turns out to be a surprisingly big problem. One has to do a global dataflow analysis just to discover which pointer variables could ever point at array elements.

Re: C’s Biggest Mistake (2009)

#225

Post by raverbashing »

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?

By number of new projects using it (without counting legacy code)

Nobody would do a project in C today with Go/Rust/C++ etc unless it's for a very specific situation

Re: C’s Biggest Mistake (2009)

#226

Post by erik_seaberg »

knaq wrote: post #211
brundolf wrote: post #195

Earlier quoted context omitted.

Ok, but you didn't just say this should be possible, you said it should be the default best-practice . Even if it were useful in a handful of cases, this would be a terrible default way of doing things.

I didn't say it should be the default, but yes it should be. It is for structs. We can have giant structs. I've seen some over a megabyte in size. The default is that the callee gets a copy. (depending on the ABI it could be in the "wrong" stack frame, but it is a distinct copy) Are we having huge problems with structs being passed by value? I don't think so. Normal people pass pointers, except when they actually wan…

The weird thing is that the compiler obviously knows how to copy an array, because you can pass a copy of a struct that contains an array. I have a vague impression that early versions of C couldn't pass either structs or arrays, only scalars and pointers.

Re: C’s Biggest Mistake (2009)

#227

Post by jes »

peterwwillis wrote: post #140
leetcrew wrote: post #137

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. not saying you're necessarily wrong (c is definitely simpler than rust), but I think most people would write a similar comment for whatever language they feel most comfortable with. I write c++ most days. even though it's the most verbose and complicated language I've ever used, I can still probably get…

Agreed - in that I write it in Perl if I need it to just work right now. Perl is still, to me, the most useful programming language for completing a generic program in the smallest amount of time. (Part of that is due to CPAN, and part to the gazillion built-in features of Perl 5)

I agree. I’m an older programmer (almost 61) and I’ve been using Perl for a long time - maybe 20 or 25 years. I reach for it when a job feels like a bit too much for a bash (1) script.

I don’t go out of my way to teach or suggest Perl to my younger colleagues. I don’t know why that is. They don’t usually reach for Python, which I think would probably be their best choice.

Maybe I’m just a curmudgeon ... and by the way, can you please stay off my lawn?

:)

Re: C’s Biggest Mistake (2009)

#228

Post by jes »

rightbyte wrote: post #24
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 proposal is just syntactic sugar for an size argument. It doean't add or solve anything really.

I may be wrong, but something that you and I recognize as syntactic sugar may not be recognized as such by other, less experienced programmers.

So those programmers might just use the sugared approach and avoid the problem of writing past the end of an array, without ever knowing how tedious and/or difficult debugging such problems can be. They might sort of never even realize that they dodged a bullet simply due to some sugar.

How do you see it?

Re: C’s Biggest Mistake (2009)

#229

Post by pjmlp »

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?

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.

Re: C’s Biggest Mistake (2009)

#230

Post by pjmlp »

giancarlostoro wrote: post #200
konjin wrote: 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?

> By what measure would C be losing ground? When we start seeing Rust or similar being used instead of C would be a good metric and / or major OS development.

Like C++ on Windows, Arduino, ARM mbed, macOS,...
Post reply on HN