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

81–90 of 382 posts

Re: C’s Biggest Mistake (2009)

#81

Post by ratww »

rumanator wrote: post #75
WalterBright wrote: post #59

Earlier quoted context omitted.

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

C has been "losing ground" not because of random per peeves of those who never wrote a line of code in C but because since C's last standard update there have been other programming languages that offer developers something of value so that the trade-off between using C or any alternative starts to make technical sense. It also helps that C's standardization proceeds in ways that feel somewhat between sabotage and ut…

> 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 vs strnlen/etc).

Re: C’s Biggest Mistake (2009)

#82

Post by boring_twenties »

rumanator wrote: post #75
WalterBright wrote: post #59

Earlier quoted context omitted.

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

C has been "losing ground" not because of random per peeves of those who never wrote a line of code in C but because since C's last standard update there have been other programming languages that offer developers something of value so that the trade-off between using C or any alternative starts to make technical sense. It also helps that C's standardization proceeds in ways that feel somewhat between sabotage and ut…

Pro tip: Google the name of the person before responding to them, it can help avoid the taste of foot in your mouth which you are currently experiencing.

Re: C’s Biggest Mistake (2009)

#83

Post by bumblebritches5 »

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.

Walter, I honestly just can't trust your judgement on the future of C or C++, because all I ever see is you pushing D anytime you comment.

This seems like just another gimmick to push D tbh.

Re: C’s Biggest Mistake (2009)

#84

Post by Reelin »

enriquto wrote: post #31
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 real troubles are undefined behavior and aliasing. Buffer overflows are just a well known gimmick of the language that is more or less controllable with some discipline. Aliasing is hell. You cannot even use a global variable safely!

Isn't much of the undefined behavior in C that people love to complain about intentionally left in the standard for the purpose of optimization? Similarly, bounds checks are necessary in insecure contexts (ie most places) but you probably don't want them slowing down (for example) an MD simulation.

Edit: But to be clear, C really ought to have first class arrays. If you truly don't want bounds checks in a specific scenario for some arcane reason, you could still explicitly pass a raw pointer and index on that. (The same as you would in any sane systems language.)

Re: C’s Biggest Mistake (2009)

#85

Post by nordsieck »

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.

> C code is being replaced by Rust fast.

One of the key areas C is used that Rust cannot be used easily is in limited embedded devices. That looks like it'll be the case for at least 10 years and probably much longer than that.

Re: C’s Biggest Mistake (2009)

#86

Post by quelsolaar »

rightbyte wrote: post #68
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.

That mindset doesn't cover sizeof(a) properly.

I agree, that's an inconsistency I would rather fix, then the one OP suggests.

Re: C’s Biggest Mistake (2009)

#88

Post by carlmr »

ncmncm wrote: post #42
forrestthewoods wrote: post #21

Earlier quoted context omitted.

How have they leaked into Rust? I thought Rust had no implicit conversions?

It does, however, have integer overflow, in release mode. So if you do code a conversion, you can end up with a value different from the source.

But that's because Rust designs for zero cost abstractions in release mode. Overflow checking is not zero cost, so it's only enabled in debug mode, which is the maximum safety possible here while keeping it zero cost at (release) runtime. Without dependent types or something similar I don't know if it would be possible to check bounds.

Re: C’s Biggest Mistake (2009)

#89

Post by unsatchmo »

mhh__ wrote: post #45
fortran77 wrote: post #29

Earlier quoted context omitted.

C will survive, if just for embedded/systems programming where you need a "portable assembly language" that can run on the simplest CPUs.

That's because of sunk-cost rather than design. Thanks to LLVM and GCC you can happily write embedded code in a higher level language, but the vendors don't bother supporting it because a lot of embedded coding isn't really what we would call software (no tests etc.)

The higher level languages are kind of the problem though. I need things like the ability to know the layout of my structs.

Re: C’s Biggest Mistake (2009)

#90

Post by mhh__ »

unsatchmo wrote: post #89
mhh__ wrote: post #45

Earlier quoted context omitted.

That's because of sunk-cost rather than design. Thanks to LLVM and GCC you can happily write embedded code in a higher level language, but the vendors don't bother supporting it because a lot of embedded coding isn't really what we would call software (no tests etc.)

The higher level languages are kind of the problem though. I need things like the ability to know the layout of my structs.

Rust, D, Whatever let you control the layout of your struct.
Post reply on HN