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

321–330 of 382 posts

Re: C’s Biggest Mistake (2009)

#321

Post by neverartful »

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…

"relying on the programmer to correctly keep track of the size"

I don't interpret Walter's suggestion that way. Of course, I might be wrong. Since the compiler must know the size of the array at the time it's declared, my thinking is that the compiler is smart enough to pass the size without the programmer having to even think about it.

Re: C’s Biggest Mistake (2009)

#322

Post by [deleted] »

hanche wrote: post #313
YeGoblynQueenne wrote: post #310

Earlier quoted context omitted.

Thank you for the new knowledge that "eso" is pronounced similar to "iso" in some dialects of English, I didn't know that. However, the word "isoteric" is more correctly spelled (in non-phonetic spelling) as esoteric . The prefix "eso-" means "inside" in Greek, as in "esothermic", or "esophagus". The prefix "iso-" means "equal", as in "isomorphism", "isosceles", "isometric", etc.

Maybe dial back the sarcasm a notch or two?

[deleted]

Re: C’s Biggest Mistake (2009)

#323

Post by boring_twenties »

rixed wrote: post #183
boring_twenties wrote: post #82

Earlier quoted context omitted.

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.

Thank you for enforcing arguments of authority.

What argument from authority is being made by anyone?

The GP decided, out of the blue, to accuse the author of never having written a line of C code in his life. That's kind of inappropriate in any context, IMO, but just downright laughable when the author is well-known for singlehandedly writing several compilers and a whole new language.

Re: C’s Biggest Mistake (2009)

#324

Post by chongli »

hanche wrote: post #313
YeGoblynQueenne wrote: post #310

Earlier quoted context omitted.

Thank you for the new knowledge that "eso" is pronounced similar to "iso" in some dialects of English, I didn't know that. However, the word "isoteric" is more correctly spelled (in non-phonetic spelling) as esoteric . The prefix "eso-" means "inside" in Greek, as in "esothermic", or "esophagus". The prefix "iso-" means "equal", as in "isomorphism", "isosceles", "isometric", etc.

Maybe dial back the sarcasm a notch or two?

I’m pretty sure they’re a native speaker of Greek, given their name on GitHub.

Re: C’s Biggest Mistake (2009)

#325

Post by boring_twenties »

xmprt wrote: post #168
leptons wrote: post #155

Earlier quoted context omitted.

Someone once said COBOL would disappear. C will still be used long after you and I and everyone here have returned to dust.

Try becoming a COBOL developer and see how that works for you. Likening C to COBOL isn't doing it any favors.

What's the implication here? I only know one COBOL developer but they seem to be doing quite well for themselves, making over $400k a year for something like 15 hours of work a week.

Re: C’s Biggest Mistake (2009)

#326

Post by geocar »

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.

I hold hopes people will discover as I did, the Real real problem with the C language is the C library and the diglossia. Maybe that's a different language[1], but it's one you get with just a bit of #define and discipline.

For example: If you had just put the length before the array buffer, you could've saved a stall in almost every use. That's a problem with out-of-order processing that's hard to fix. Maybe your compiler will get sufficiently smart, or maybe CPUs will collude with the memory controller (or something else amazing will happen), but those things are really hard. However we fixed it ourselves; we didn't need anyone to do it for us, because (due to laziness or luck) C gave us enough of the tools we needed to do what we needed to do.

I think that's a bigger deal than buffer overflows, as unpopular an opinion as that is.

[1]: https://news.ycombinator.com/item?id=22010895

Re: C’s Biggest Mistake (2009)

#327

Post by shaklee3 »

konjin wrote: post #153
teej wrote: post #54

Earlier quoted context omitted.

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.

There's a lot of truth in it, but for a slightly different reason. Almost everyone I work with knows or writes C regularly. They're usually very senior people, and not once have I ever heard them talk about a blog, let alone write one. so there is this large group of C practitioners out there that simply don't know or care about all these other things happening around them. To some degree, it doesn't matter since there are plenty of jobs doing this.

Re: C’s Biggest Mistake (2009)

#328

Post by rurban »

I agree that missing bounds checks are the biggest problem, with the unhealthy attitude of dismissing the Annex K for political reasons. My Safe C library has only adoption with the big players.

But even weirder is the total lack of a proper string library. Nobody but Microsoft uses whar, and they are the only ones with the proper whar_t size. Everybody else was wrong with size 4. But nowadays it should be clear that only u8 is the only way forward, C++ even adopted now char8_t for it. But they all still ignore the unicode problems with an overly simplistic, glorified null-terminated memory buffer library. These are not strings anymore nowadays. Strings have multiple representations of characters in unicode, strings need the unicode version to be exposed which changes every year. They need a proper fold case and norm API, otherwise you cannot compare them, so you cannot search for strings. Grep would be happy to find unicode strings, but it still cannot. coreutils still cannot do unicode in 2020.

Also the complete lack of security, esp with names, ie identifiers. Such as pathnames. Most filesystems just ignore security, spoofing, bidi changes, mixed scripts as if this problem does not exist at all. Strings are not normalized, not properly fold cased.

The _l locale mess, it still relies on global runtime state, which is not compile-time optimizable, in opposition to _l or simply just a new u8 API. Not reentrant. Not compile-time optimizable. It's a huge mess.

gcc cannot do compile-time constexprs checks, only clang can, leading to up to 200x faster libc code. gcc cannot do user-defined warnings of errors.

glibc, FreeBSD libc, musl, none of it fixes anything.

Re: C’s Biggest Mistake (2009)

#329

Post by james412 »

pjmlp wrote: post #236
james412 wrote: post #121

Earlier quoted context omitted.

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

Solaris uses SPARC ADI to great success, iPhone X has pointer validation, and Android 11 has made the work to require ARM MTE in future releases.

Pointer tagging is a completely different tech that requires no runtime knowledge of the length of an array

Re: C’s Biggest Mistake (2009)

#330

Post by asveikau »

pjmlp wrote: post #307
Gibbon1 wrote: post #213

Earlier quoted context omitted.

That's the way I interpreted it because it's true. A lot of the criticisms are misdirected one by people that haven't used C except being forced to use it for few assignments in school, C++ jockeys that think C is the 30 year out of date version of C that's supported by C++, and people that haven't used it at all for anything real. I also agree that what the standard committee has been doing for the last 20 years amo…

So what the improvements between C89 and C18 in regards to UB and security, for any ISO C compliant compiler?

Between c89 and c18 is close to 30 years.

What about between c99 and c18? Is there anything you can think of? I think the _s() functions, advertised as security features, are a weak effort. Anything else come to mind?

Post reply on HN