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

121–130 of 382 posts

Re: C’s Biggest Mistake (2009)

#121

Post by james412 »

kens wrote: post #111

C's pointers wouldn't be an issue if the world had used the Intel iAPX 432 processor instead of the 8086. The iAPX 432 included bounds checking for every array in hardware (among many other features), so it was impossible to make an out-of-bounds access. Unfortunately the iPAX 432 was delayed, so Intel introduced the 8086 as a stopgap processor and computers have been using the x86 architecture ever since. It's inter…

C-the-language has no concept of size-tagged arrays at runtime, and I guess it's baked in deeply due to the various guarantees made about sizeof(array), &array[0], and ability to cast &array[0] back to the original array. The iAPX hardware would have gone unused

Re: C’s Biggest Mistake (2009)

#122

Post by diegocg »

ajsnigrutin wrote: post #32
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.

> I don't see a future where C survives I've been seeing those exact words for decades now, and C is still going strong. Every few year a new language comes, somes writes something in it, that was written in C before, someone might even write a basic OS in it, and after a few years, that language is almost forgotten, a new one is here, and again, someone is writing something in it, but in the end, we still use C for…

Usage of C in new projects has fallen dramatically in the latest decades. It used to be the case that C was considered a general purpose programming language and applications such as Evolution were written in it. Today big applications in C are increasingly rare, and Rust is only accelerating this trend - nobody wants to have buffer overflows anymore.

Re: C’s Biggest Mistake (2009)

#123

Post by ratww »

WalterBright wrote: post #30
rightbyte wrote: post #24

Earlier quoted context omitted.

The proposal is just syntactic sugar for an size argument. It doean't add or solve anything really.

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.

> In my experience with language design, a little bit of syntactic sugar can have transformative results.

I agree 100%. This also reminds me of this article:

https://nibblestew.blogspot.com/2020/03/its-not-what-program...

HN discussion: https://news.ycombinator.com/item?id=22696229

Re: C’s Biggest Mistake (2009)

#124

Post by mark-r »

chadcmulligan wrote: post #71

Niklaus Wirth would concur - that was similar to his argument for pascal - strings contain a size.

It's a shame that Niklaus Wirth doesn't get more respect and attention. But some of his ideas were just a little ahead of their time - I think the typical size for a Pascal string was just a single byte, which was a bit too limiting.

Re: C’s Biggest Mistake (2009)

#125

Post by johnisgood »

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.

I believe we will come back to C eventually. Kind of irrelevant but: I learnt C by writing mods for ioquake3 forks. :) Fun times. I was about 13 years old.

Re: C’s Biggest Mistake (2009)

#126

Post by jstimpfle »

kens wrote: post #111

C's pointers wouldn't be an issue if the world had used the Intel iAPX 432 processor instead of the 8086. The iAPX 432 included bounds checking for every array in hardware (among many other features), so it was impossible to make an out-of-bounds access. Unfortunately the iPAX 432 was delayed, so Intel introduced the 8086 as a stopgap processor and computers have been using the x86 architecture ever since. It's inter…

> so it was impossible to make an out-of-bounds access.

That's a strong claim for something as vaguely defined as "the length of an array."

What if I allocate a huge array of memory and emulate another processor using that memory? What if I subpartition an array? What if I overallocate an array to avoid reallocations?

Re: C’s Biggest Mistake (2009)

#127

Post by AnimalMuppet »

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.

Would you care to define "finished" tightly enough that we can objectively evaluate whether or not it happens? And put a time frame on it?

Re: C’s Biggest Mistake (2009)

#128

Post by leetcrew »

colejohnson66 wrote: post #95
rowanG077 wrote: post #44

Earlier quoted context omitted.

I don't feel it's so bad. You have a a specific flag to tell the compiler to show warnings if you have any.

Why should I need to use a flag to fix something that doesn’t make sense? I can understand implicit up -conversions, but down -conversions too?

you can certainly argue it should have been a default warning from the beginning, but mistakes were made and it's a bit too late to change that. people don't like when old, battle-tested code suddenly starts spewing a new warning everywhere after a compiler update.

in reality, most production build systems at least use -Wall (or their compiler's equivalent) and possibly also have a list of specific warnings turned on/off for different parts of the code. it would be nice to have some saner defaults, but it just doesn't matter that much.

Re: C’s Biggest Mistake (2009)

#129

Post by quelsolaar »

Cyph0n wrote: post #107
quelsolaar wrote: post #57

Earlier quoted context omitted.

I think a better way to think about is to say that when you type: int a[10]; you allocate 10 integers and "a" is the pointer to the first one of them. Arrays are just memory, just like what you get wen calling malloc, and memory is accessed using pointers in C.

Minor nitpick: there is no allocation going on here - you’re simply reserving a fixed-size buffer on the stack (assuming the array is local to a function).

I would call that a stack allocation, but yes they are slightly different. In my mind its a feature that arrays allocated on the stack and heap can interchangeably be given as an argument to a function.

Re: C’s Biggest Mistake (2009)

#130

Post by bsder »

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.

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

Is this really "simple, easy, backwards compatible"?

I think Rust kind of counterexamples this.

While Rust can throw around slices [] (effectively runtime length), throwing around [u8; 8] and [u8; 9] (compile time length) to the same function gets nasty.

Perhaps all the constexpr work in Rust will make this a lot easier.

Post reply on HN