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

Re: C’s Biggest Mistake (2009)

#151

Post by torstenvl » Sun, Sep 13, 2020, 1:36 AM UTC

SV_BubbleTime wrote: post #109

torstenvl wrote: post #99

Earlier quoted context omitted.

So... don't use array syntax in the function prototype and definition? The proposal doesn't PROHIBIT passing a pointer, it would just offer an option to pass a fat array.

I think you mean fat pointer. And yea, that’s nice for people that don’t care their 4bit array has 64bits of native type reserved... I think other people would care. So, I go back to the idea that it seems unlikely this would ever be an official C change.

I think you and I are talking past one another.

Currently, f(a[]) with declaration void f(int a[]) passes a pointer to the first element, with no additional overhead.

Under the proposal, f(a[]) with declaration void f(int a[]) passes a pointer to the first element, with no additional overhead.

Help me understand why "other people would care"? What is the negative impact on someone who would not use the a[..] functionality?

Re: C’s Biggest Mistake (2009)

#152

Post by identity0 » Sun, Sep 13, 2020, 1:51 AM UTC

Ar-Curunir wrote: post #51

xxpor wrote: post #37

Earlier quoted context omitted.

Isn't that what asan/ubsan is for? Granted, it's not static analysis, but it should catch most aliasing related errors, no?

only if your tests exercise that code path

You can't do compile time bounds checking, if that's what you're implying.

Re: C’s Biggest Mistake (2009)

#153

Post by konjin » Sun, Sep 13, 2020, 1:58 AM UTC

teej wrote: post #54

Upvoter33 wrote: post #49

Earlier quoted context omitted.

"C is finished if it doesn't address the buffer overflow problem" You should keep making this prediction ... one day you might be right! :)

C code is being replaced by Rust fast. The only limit is how quickly programmers can become good at Rust. It's already happening.

It isn't. You can tell how much a language is used by the inverse of the number of blogposts about it. People who have jobs don't have the time to write about how they would solve problems using that language, because they already are and have better things to do in their free time.

Re: C’s Biggest Mistake (2009)

#154

Post by konjin » Sun, Sep 13, 2020, 2:01 AM UTC

prakis wrote: post #142

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.

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.

The first thing you do to see if a new processor has bugs is to port a forth interpreter for it.

The first thing you do to see if a new processor is ready for prime time is to port a c compiler for it.

The people who talk about rust replacing c are the type of people who thing that GTK is a reasonable C project.

Re: C’s Biggest Mistake (2009)

#155

Post by leptons » Sun, Sep 13, 2020, 2:04 AM UTC

datman347 wrote: post #146

kortilla wrote: post #145

Earlier quoted context omitted.

You misunderstand what the conversation is that’s occurring. The parent implied the person had never written C.

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.

Re: C’s Biggest Mistake (2009)

#156

Post by konjin » Sun, Sep 13, 2020, 2:05 AM UTC

WalterBright wrote: post #59

Upvoter33 wrote: post #49

Earlier quoted context omitted.

"C is finished if it doesn't address the buffer overflow problem" You should keep making this prediction ... one day you might be right! :)

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?

Re: C’s Biggest Mistake (2009)

#157

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

WalterBright wrote: post #113

ratww wrote: post #81

Earlier quoted context omitted.

> C has been "losing ground" not because of random per peeves of those who never wrote a line of code in C This is not a random pet peeve, and WalterBright is as far as you can get from someone "who never wrote a line of code in C". This is the cause of numerous security bugs in the past and currently, and the reason most C material written in the 70s/80s is unsafe to be used today (mostly due to usage of strlen/etc…

Frankly I never would have made the proposal if I didn't love C. I've made proposals to add D features to C++, too.

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)

Re: C’s Biggest Mistake (2009)

#158

Post by kps » Sun, Sep 13, 2020, 2:07 AM UTC

josephg wrote: post #106

blogant wrote: post #34

Earlier quoted context omitted.

> 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…

Huh? In what way is C’s books, documentation or build system superior to that found in other languages? Most languages have plenty of good books written about them. And plenty of code examples online. I can’t speak for other languages but I find MDN (Javascript) and the rust docs consistently better than C’s man pages. Ruby’s documentation is great too. As for build systems, autotools is a hilarious clown car of a di…

> in rust “cargo build” will build my project correctly on any platform

I've got a parts drawer full of controllers that says it won't.

Re: C’s Biggest Mistake (2009)

#159

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

ratww wrote: post #157

WalterBright wrote: post #113

Earlier quoted context omitted.

Frankly I never would have made the proposal if I didn't love C. I've made proposals to add D features to C++, too.

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

Re: C’s Biggest Mistake (2009)

#160

Post by WalterBright » Sun, Sep 13, 2020, 2:15 AM UTC

prakis wrote: post #142

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.

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.