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

111–120 of 382 posts

Re: C’s Biggest Mistake (2009)

#111

Post by kens »

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 interesting to think that if history had gone a bit differently, whole classes of security problems would not exist.

https://en.wikipedia.org/wiki/Intel_iAPX_432

Re: C’s Biggest Mistake (2009)

#112

Post by diegocg »

johnisgood wrote: post #98
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.

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.

Re: C’s Biggest Mistake (2009)

#113

Post by WalterBright »

ratww wrote: post #81
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…

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

Re: C’s Biggest Mistake (2009)

#114

Post by syrrim »

leetcrew wrote: post #48
SamReidHughes wrote: post #5

The biggest mistake to me feels like implicit integer conversions. That's where C feels like it's really out to get you.

on a somewhat related note, I've always wished for something like `explicit` that prevents assigning different typedefs for the same underlying type to each other. like suppose I have two types, WorldVec (vector in worldspace) and ViewVec (vector in view/sceenspace). under the hood they are both typedefs for float[3], so I can freely assign them back and forth. but any vector operation that mixes the types would almo…

structs

Re: C’s Biggest Mistake (2009)

#115

Post by AnimalMuppet »

pritovido wrote: post #94

I actually believe the way C works is great, as simple as it could be and it gives you power to do exactly what you want, they way you want it. I would certainly hate(and would continue using them btw) that they remove normal pointers from C. It would be like removing s expressions from lisp. I believe that the solution to this "mistake" is just not using c directly, using other languages to write C code for you, or…

My solution is different: Don't use dynamically-allocated variable-sized buffers unless you have to.

C++ gives you more tools for avoiding them than C, BTW.

Re: C’s Biggest Mistake (2009)

#116

Post by ImprobableTruth »

rumanator wrote: post #79
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 Meanwhile C is running strong since the 70s. > the lack of package manager What do you call linux distro's package managers then? I mean, in distributions like Debian you can even download a package's source code with apt-get.

>What do you call linux distro's package managers then?

If you want to count them as package managers, they're by far the worst ones of all the well known languages (with some notable exceptions e.g. guix's and nixos's).

They're not portable between distributions or even different versions of the same distribution (!), since it's non-trivial to install older versions of libraries (or, hell, different versions of the same library at the same time). Not to mention that it's a very manual and tedious process in comparison to all the other language specific package manager. 'Dependency hell' is a problem virtually limited to distro package managers (and languages like C and C++ that depend on them).

Getting older, unmaintained C programs to run on Linux is an incredibly frustrating experience and I think a perfect demonstration of how the current distro package manager approach is wholly insufficient.

Re: C’s Biggest Mistake (2009)

#117

Post by Reelin »

leetcrew wrote: post #48
SamReidHughes wrote: post #5

The biggest mistake to me feels like implicit integer conversions. That's where C feels like it's really out to get you.

on a somewhat related note, I've always wished for something like `explicit` that prevents assigning different typedefs for the same underlying type to each other. like suppose I have two types, WorldVec (vector in worldspace) and ViewVec (vector in view/sceenspace). under the hood they are both typedefs for float[3], so I can freely assign them back and forth. but any vector operation that mixes the types would almo…

This has always bugged me as well. I've generally solved this by wrapping things in a struct. Type checking will use the (incompatible) wrappers and a modern compiler should optimize them away. To avoid strict aliasing violations when converting between equivalent wrapped types you can use a union and employ a function to hide the verbosity.

I have no idea if this is the "right" way to do things, but it seems to work.

Re: C’s Biggest Mistake (2009)

#118

Post by pvorb »

makecheck wrote: post #104

Unfortunately working with dynamically-allocated buffers is still a thing; adding array syntax just favors one form of size specification without solving the other case. Although C is usable on many types of hardware, interesting things could be done, e.g. on desktop OSes if certain hardware-specific extensions were made. One of the things I wish we could do with our now-absurdly-large pointers (64-bit) is to reserve…

The JVM chose to compress object pointers instead, which I think is a quite elegant optimization: https://stackoverflow.com/a/25120926/432354

Re: C’s Biggest Mistake (2009)

#119

Post by mark-r »

Gibbon1 wrote: post #36
WalterBright wrote: post #7

Earlier quoted context omitted.

The #1 undetected bug problem with C programs is buffer overflows. Experience shows it is extremely difficult to verify that arbitrary C code doesn't have buffer overflows in it. Assistance from the core language design can improve things a great deal. D allows passing both raw pointers as parameters and pointer/length pairs. It's up to the user to choose. In practice, people have simply moved away from using raw poi…

All of this I agree with. In a better world 'arrays' would have added in the 1980's. The arguments about memory limitations is spurious since if you're writing good code you always pass a pointer and the length. Always no exceptions. Yeah and all the string functions should have been marked as depreciated with C89 and fully depreciated with C99.

Yes, you can always pass a pointer and a length explicitly. And that's what the "safe" versions of e.g. string functions do. But it's still incumbent on you as the programmer to use them properly. It would still be beneficial to have a compiler mode where all that was done for you automatically and it was impossible to have a buffer overrun.

Re: C’s Biggest Mistake (2009)

#120

Post by non-entity »

unsatchmo wrote: post #67
non-entity wrote: post #39

Earlier quoted context omitted.

As much as I dislike C > There are only two kinds of languages: the ones people complain about and the ones nobody uses. This unfortunately seems to mostly hold true.

Porque no los dos? There are a few languages that nobody uses and also everybody seems to complain about.

> mostly
Post reply on HN