4 ms·
To me this idea sounds a lot like "why do we need IPV6? Why not keep IPV4 and add a few bytes?" except it's effectively almost the same amount of breakage. Eith
by simias 6y ago
To me this idea sounds a lot like "why do we need IPV6? Why not keep IPV4 and add a few bytes?" except it's effectively almost the same amount of breakage. Either you're C-compatible or you're not.
Making C memory-safe by adding extra annotations to allow for static zoning/borrow checking is possible, but the churn involved is probably not much different than rewriting in a different language. See Cyclone for instance if you want to see what such an approach looks like.
On top of that modern languages have facilities that are seriously lacking from C, memory safe or not. C's error handling is atrocious, C doesn't have (standard) destructors, C doesn't have type inference, C doesn't have algebraic types, C doesn't have proper string/collection support etc...
I like C quite a lot, it's probably the language I know best, but it's definitely very outdated. I think in the not so far future it'll be almost entirely replaced outside of legacy applications, hopefully with Rust. I think the watershed moment will be when the Linux kernel is rewritten in an other language, which definitely won't happen overnight but at this point I'm fairly certain that it will happen within a couple of decades.
- stephen82 6y agoYour wish might become reality soon https://gustedt.wordpress.com/2021/01/12/improve-type-generic-programming/ https://gustedt.wordpress.com/2021/01/12/improve-type-generi...
- wmanley 6y ago> To me this idea sounds a lot like "why do we need IPV6? Why not keep IPV4 and add a few bytes?" except it's effectively almost the same amount of breakage. [DJB disagrees](https://cr.yp.to/djbdns/ipv6mess.html https://cr.yp.to/djbdns/ipv6mess.html). Quote: >The IPv6 designers made a fundamental conceptual mistake: they designed the IPv6 address space as an alternative to the IPv4 address space, rather than an extension to the IPv4 address space. > Either you're C-compatible or you're not. If we take this black and white approach then we must say that C++ is not C compatible just like Ada isn't C compatible. The reality is that C++ being broadly a superset of C was integral to its adoption, even though that compatibility isn't perfect. It enabled easy incremental porting of projects. This is really just a nit though. I do agree with your conclusions.
- simias 6y agoWith all due respect I disagree with DJB here. I can't see how his proposal would significantly improve the current status quo. Note step one of his self-described "straightforward" transition plan (emphasis mine): >0123456789abcdef0123456789abcdef to 192.5.6.30: The client sends a UDP packet to the .com DNS server asking for the address of www.google.com. The client software, intermediate computers, and server software have all been upgraded to handle the client's extended address. A lot of work in this one "straightforward" step. I know that DJB is a great network engineer, so I'm willing to consider that I'm missing the point here, but at the very least I don't find this particular exposé very convincing. >If we take this black and white approach then we must say that C++ is not C compatible just like Ada isn't C compatible. Agreed, in a parent comment I mention C++ being effectively mostly compatible with C. But I can't really imagine how you could do something like that with a memory-safe subset of C. The changes involved are pretty thorough (you basically either need a garbage collector or a borrow checker). Things like raw pointers (especially nullable ones) can't really exist in their current form in a memory safe language.