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

341–350 of 382 posts

Re: C’s Biggest Mistake (2009)

#341

Post by baby »

johnisgood wrote: post #315
ComputerGuru wrote: post #212

Earlier quoted context omitted.

I use stb myself, so I have no qualms with that. The point is rather that GP was discussing praise for C’s standard library, and even the most portable single-file include-only dependency remains just that: an external dependency that isn’t part of the C standard library (and no, posix isn’t C).

Does it make much of a difference though? Take the hyped Rust for example. Most useful stuff is in crates, i.e. an external dependency. No one seems to have a problem with that. Personally I do not mind using libraries typically installed by the Linux distribution's package manager anyways. If the question is whether or not I think the C standard library could be improved, then yes, I would say it could, but I do not…

Rust not having a good standard library is a huge problem. This increases the risk of a rust codebase due to the high number of third party dependencies.

Re: C’s Biggest Mistake (2009)

#342

Post by gallier2 »

bumblebritches5 wrote: post #83
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.

Did you see that the article is from 2009?

Re: C’s Biggest Mistake (2009)

#343

Post by hanche »

YeGoblynQueenne wrote: post #332
hanche wrote: post #313

Earlier quoted context omitted.

Maybe dial back the sarcasm a notch or two?

Many apologies - I was not being sarcastic and I'm sorry that this is how my comment came across. As chongli says I'm a native speaker of Greek and I really didn't know how "eso" is pronounced by native English speakers. I've lived for 15 years in the UK and I'm still surprised to hear how people pronounce the more obscure words in their language (some of which come from Greek).

Oops, sorry, I apologise for the mistake. I have seen too much bad behaviour on the 'net, so naturally I assumed the worst. It's a valuable lesson at the modest cost of a few karma points. (I guess I violated HN guidelines too, there. Good thing I don't have the power to downvote yet. I might have done so, and never discovered my mistake.)

Re: C’s Biggest Mistake (2009)

#344

Post by david2ndaccount »

Koshkin wrote: post #314
dependenttypes wrote: post #311

Earlier quoted context omitted.

void f(size_t n, int v[n]) is valid C.

Semantically though, the second argument is still just a naked pointer.

That’s why you use the proper declaration of

  void f(size_t n, int (*v)[n])
instead.

Re: C’s Biggest Mistake (2009)

#345

Post by WalterBright »

asveikau wrote: post #93
rumanator wrote: post #75

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

Maybe people are voting this down because they think it's directed at Walter Bright in particular, but I think there is actually some truth in the harsh comment. Nothing about Walter Bright in this statement, but some of the harshest criticisms from others I have seen of C are not from expert practitioners in C. People who are experts and also critics seem to have a more practical, realistic, nuanced critique, that u…

I also have extensive (20 years) experience with the solution I proposed.

Re: C’s Biggest Mistake (2009)

#346

Post by WalterBright »

saagarjha wrote: post #276
enriquto wrote: post #31

Earlier quoted context omitted.

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!

> You cannot even use a global variable safely! Sorry? I’m unsure what you mean here, because there are plenty of ways to use globals in ways I would call “safe”: no undefined behavior, correct output, …

In one C file you can declare a global:

    int x;
and in another:

    int* x;
and you'll be mixing pointers and ints and it won't be detected.

Re: C’s Biggest Mistake (2009)

#347

Post by WalterBright »

bumblebritches5 wrote: post #83
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.

Your choices are:

1. the judgement of people in the industry, who will always be biased

2. the judgement of people not in the industry, who don't know what they're talking about

As for me, I still sell a C and C++ compiler https://www.digitalmars.com/shop.html

Re: C’s Biggest Mistake (2009)

#348

Post by WalterBright »

bsder wrote: post #208
ComputerGuru wrote: post #201

Earlier quoted context omitted.

Not constexpr, this is solved by constant generics (the famous RFC 2000) with the array bound as a constant “generic” parameter/value. I’ve been pushing for this feature for many years and have been playing with it since it first landed in nightly. It works quite well.

Sorry, I misspoke. But this wasn't meant to be about Rust. My point was that: if you dump slices/fat pointers into C, how does it help? Slices/fat pointers and the corresponding checks are a runtime thing, and that's absolutely anathema to a lot of C programmers. If it's not anathema to the C programmer, they probably aren't in C anyway. So, now you need a way so that compiled slices/fat pointers mean something, and…

The checks can be at compile time, given how good the data flow analysis is in the compiler. The rest are at runtime, presumably coming with a compiler switch to turn them off.

Most people using D leave the checks on.

Even without the checks, however, I can vouch that implicitly carrying around the length of the array with the array pointer is a vast improvement in the clarity of the written code.

Re: C’s Biggest Mistake (2009)

#349

Post by WalterBright »

leetcrew wrote: post #46
eps wrote: post #35

Earlier quoted context omitted.

I'm not sure whom this proposal is aimed at exactly. Any production-quality C code will already use a (pointer + count) combo when passing arrays to a function, which is something that will still be needed under your proposal because the vast majority of arrays is dynamically sized. So unless all arrays in C are given the fat pointer treatment, I don't really see how what you suggest would make much of a difference.…

pointer + size does not really fix anything, as you are relying on the programmer to correctly keep track of the size. I'm not even sure what alternative this improves upon. even more error-prone null value marking the end? praying the array will be big enough (looking at you, gets!)? unless you have a team of incredibly diligent coders, people are going to read past the end of bare arrays over and over again. one sp…

> misinterpret the meaning of a variable named `size`

Quite right. I use, and highly recommend, the convention that `size` is for number of bytes, `length` is for number of elements, and `capacity` for the allocated number of elements.

    assert(length * sizeof(element) == size);
    assert(length

Re: C’s Biggest Mistake (2009)

#350

Post by WalterBright »

true_religion wrote: post #63
leetcrew wrote: post #46

Earlier quoted context omitted.

pointer + size does not really fix anything, as you are relying on the programmer to correctly keep track of the size. I'm not even sure what alternative this improves upon. even more error-prone null value marking the end? praying the array will be big enough (looking at you, gets!)? unless you have a team of incredibly diligent coders, people are going to read past the end of bare arrays over and over again. one sp…

Would you just wrap the pointer and size in a strut, then only iterate the array via a library of functions that check the size first? I don't code c full time, but it's what I have always done when needing to use c via ffi to get a speed up in a dynamic language.

You can, but since C doesn't have templates or operator overloading this becomes awkward and unappealing.
Post reply on HN