4 ms·

Ask HN: What's the economic impact of missing string type in C?

3 points by awinter-py 10y ago

How would the course of history have changed if C had, from the beginning, a safe string type?

detaro 10y ago
You'll likely be familiar with this article, but I'll leave it here for other readers and the off chance that you are not: https://queue.acm.org/detail.cfm?id=2010365 https://queue.acm.org/detail.cfm?id=2010365
- wahern 10y ago
  It doesn't really answer the question, though. Experience shows that such proposals go nowhere because backwards compatibility with the PDP/11 and the finite number of programs written are much more important than the ability to write the potentially infinite number of programs in the future in an efficient and secure way. What does secure mean, here? A length-prefixed string object wouldn't have solved lifetime bugs like use-after-free, which are far more common. NUL-terminated strings are effectively an immutable type. The NUL byte tells you nothing about the size of the backing store, so nobody appends to a NUL-terminated string without being given ancillary size information. For the most part NUL-termination is irrelevant to the problem of buffer write overflows. Some kind of write overflow is usually a prerequisite for gaining control of execution remotely. Because the beauty of C lies in the manner it exposes pointers, any such alternative solution would also have to tackle the problem of deriving slices/vectors that point into larger arrays. The length-prefixed string solution doesn't solve that directly, whereas NUL-terminated strings naturally offer an elegant (if simplistic) solution for character strings. Pointers are useful in other situations. You usually don't need the power of pointers, but where they're most valuable is precisely where obvious, effective, and simple solutions are sparse. For example, pointers naturally length themselves to iteration. How many iterator interfaces has C++ gone through? Swift? Rust? Languages like C++ and Rust retain pointers because often times they're still the best model, especially in the most complex situations prone to mistakes. It has yet to be shown that there are simple solutions that are "secure" while maintaining the simplicity, transparency, and efficiency of C. (Cue Rust fans!) I don't doubt that such solutions exist, I just doubt they're as easily discoverable as assumed. C is a great language because of the tremendous expressiveness it offers for it's minimal complexity. If better expressiveness, or better "security", comes at too high a cost in productivity, there's no reason to think such a language would have triumphed over C. After all, Pascal and many other languages predated C. Regarding the PDP-11, C predates the PDP-11. The B language also used a terminator rather than a length prefix. See https://www.bell-labs.com/usr/dmr/www/chist.html The whole PDP-11 angle is both dubious history and highly speculative. It's certainly a simple and convenient narrative, though. And those are always the most fun. I'm not defending NUL-terminated strings. I agree length-prefixed strings would have been preferable. I just disagree that they would have magically resulted in substantially more "secure" code. The alternative universe where C had length-prefixed strings is certainly not one with $0 of unnecessary costs related to bugs and intrusions. Indeed, there's little reason to believe it would have alone resulted in anything more than a marginal reduction in costs.

3 points by awinter-py 10y ago

How would the course of history have changed if C had, from the beginning, a safe string type?

You'll likely be familiar with this article, but I'll leave it here for other readers and the off chance that you are not: https://queue.acm.org/detail.cfm?id=2010365 https://queue.acm.org/detail.cfm?id=2010365

wahern 10y ago
It doesn't really answer the question, though. Experience shows that such proposals go nowhere because backwards compatibility with the PDP/11 and the finite number of programs written are much more important than the ability to write the potentially infinite number of programs in the future in an efficient and secure way. What does secure mean, here? A length-prefixed string object wouldn't have solved lifetime bugs like use-after-free, which are far more common. NUL-terminated strings are effectively an immutable type. The NUL byte tells you nothing about the size of the backing store, so nobody appends to a NUL-terminated string without being given ancillary size information. For the most part NUL-termination is irrelevant to the problem of buffer write overflows. Some kind of write overflow is usually a prerequisite for gaining control of execution remotely. Because the beauty of C lies in the manner it exposes pointers, any such alternative solution would also have to tackle the problem of deriving slices/vectors that point into larger arrays. The length-prefixed string solution doesn't solve that directly, whereas NUL-terminated strings naturally offer an elegant (if simplistic) solution for character strings. Pointers are useful in other situations. You usually don't need the power of pointers, but where they're most valuable is precisely where obvious, effective, and simple solutions are sparse. For example, pointers naturally length themselves to iteration. How many iterator interfaces has C++ gone through? Swift? Rust? Languages like C++ and Rust retain pointers because often times they're still the best model, especially in the most complex situations prone to mistakes. It has yet to be shown that there are simple solutions that are "secure" while maintaining the simplicity, transparency, and efficiency of C. (Cue Rust fans!) I don't doubt that such solutions exist, I just doubt they're as easily discoverable as assumed. C is a great language because of the tremendous expressiveness it offers for it's minimal complexity. If better expressiveness, or better "security", comes at too high a cost in productivity, there's no reason to think such a language would have triumphed over C. After all, Pascal and many other languages predated C. Regarding the PDP-11, C predates the PDP-11. The B language also used a terminator rather than a length prefix. See https://www.bell-labs.com/usr/dmr/www/chist.html The whole PDP-11 angle is both dubious history and highly speculative. It's certainly a simple and convenient narrative, though. And those are always the most fun. I'm not defending NUL-terminated strings. I agree length-prefixed strings would have been preferable. I just disagree that they would have magically resulted in substantially more "secure" code. The alternative universe where C had length-prefixed strings is certainly not one with $0 of unnecessary costs related to bugs and intrusions. Indeed, there's little reason to believe it would have alone resulted in anything more than a marginal reduction in costs.