Niklaus Wirth would concur - that was similar to his argument for pascal - strings contain a size.
C’s Biggest Mistake (2009)
71–80 of 382 posts
Re: C’s Biggest Mistake (2009)
#72Earlier quoted context omitted.
> since C doesn't ... check for overflows Because it's a language, not an implementation. An implementation is free to do so (and there are such implementations after all).
That's correct! C doesn't require checking for overflows, but it also doesn't forbid implementations from doing so. both are features.
I don’t think it is possible, not without changing some parts of the C’s specification. At the very least you’d need to be able to somehow encode the length of the buffer in the pointer to it. (There is no semantic difference between a pointer to a simple, fixed-length variable and a pointer to an array.)
Re: C’s Biggest Mistake (2009)
#73Earlier 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 C being in much worse shape than C++ with respect to build system and package manager. It's slow going, but progress seems to be happening there. Are you saying both are doomed? Or is there some scenario where C++ survives without C?
I don’t see a great future for C++ either
Re: C’s Biggest Mistake (2009)
#74Earlier quoted context omitted.
I think both are, long term (think FORTRAN where it’s not particularly popular but a lot of existing code is maintained and not rewritten). C++ is actually in a slightly better spot ironically because it’s harder to integrate with. If you have a C program you can pretty easily start replacing parts with Rust. You can’t do the same with C++ which insulates it better in that sense.
Reports of Fortran's death (latest standard 2018) are greatly exaggerated (much like C). It's receded to a niche, but it's still a very important niche (numerical, HPC). Hopefully, the development of a new Fortran front end for LLVM (from PGI/Nvidia?) pans out, as this would fill a gap in LLVM's offerings, and provide more competition for ifort and gfortran.
You’re proving my point. FORTRAN is a niche language. C++ is still mainstream. It will recede but not completely disappear
Re: C’s Biggest Mistake (2009)
#75Earlier 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! :)
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 utter neglect.
Meanwhile, C is still the absolute best binary interop language devised by mankind.
Re: C’s Biggest Mistake (2009)
#76Earlier 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!
Isn't that what asan/ubsan is for? Granted, it's not static analysis, but it should catch most aliasing related errors, no?
No. There has been some effort in that direction, somebody proposed a Clang "type sanitizer" patch, but it wasn't merged.
Re: C’s Biggest Mistake (2009)
#77Author 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 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.
SQLite alone has a support contract through 2050.
C survives.
Re: C’s Biggest Mistake (2009)
#78Earlier quoted context omitted.
That's correct! C doesn't require checking for overflows, but it also doesn't forbid implementations from doing so. both are features.
I don’t think it is possible, not without changing some parts of the C’s specification. At the very least you’d need to be able to somehow encode the length of the buffer in the pointer to it. (There is no semantic difference between a pointer to a simple, fixed-length variable and a pointer to an array.)
Which is what the article proposed.
Re: C’s Biggest Mistake (2009)
#79Author 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 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.
Re: C’s Biggest Mistake (2009)
#80Earlier 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…
Lol at “never wrote a line of code in C”. Surely you are not addressing the article’s author?