231–240 of 382 posts
Earlier quoted context omitted.
In my experience with language design, a little bit of syntactic sugar can have transformative results. C's function prototypes, syntactic sugar added circa 1990, were transformative for C programming.
I wonder if a better idea (in principle) would be to have some kind of hardware implementation, sort of like a finer-grained memory segmentation.
Earlier quoted context omitted.
Isn't that what asan/ubsan is for? Granted, it's not static analysis, but it should catch most aliasing related errors, no?
I'm fully in the camp of C plus powerful analysis tools, plus a high-level language (Python or Scheme).
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.
Earlier quoted context omitted.
You misunderstand what the conversation is that’s occurring. The parent implied the person had never written C.
He never said explicitly, he was just making a general statement. Not that it matters whether he did or didn't, there's a lot of things wrong with C, it will most likely eventually disappear, but not for reasons outlined in this article. That's what he was saying.
Earlier quoted context omitted.
It's been 11 years, and C is running on more hardware than it ever has before, viz every android device. By what measure would C be losing ground?
By number of new projects using it (without counting legacy code) Nobody would do a project in C today with Go/Rust/C++ etc unless it's for a very specific situation
It's the one they know.
A C programmer isn't automatically going to switch to Rust for new projects that they would use C for, unless their goal is to use Rust.
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 inter…
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
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.
> Google the name of the person before responding to them Is it a rule at HN that you can't take someone else's name? Otherwise, there's no guarantee that you're talking to the "Real" Walter Bright... ... or that you're talking to that Walter Bright, come to think of it.
Niklaus Wirth would concur - that was similar to his argument for pascal - strings contain a size.
Wirth's Pascal didn't have a string type. You could have a fixed-length arrty of CHAR, but you couldn't have _fewer_ than 16 characters in a 16-character array, and you couldn't pass a 16-character-array to a function with a 256-character-array parameter. Only the magic ‘functions’ built in to the language like write() could accept strings of different lengths. Since this made the language worse than FORTRAN and hand…
Earlier 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.)
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.
> Google the name of the person before responding to them Is it a rule at HN that you can't take someone else's name? Otherwise, there's no guarantee that you're talking to the "Real" Walter Bright... ... or that you're talking to that Walter Bright, come to think of it.