
Ask HN: What's the economic impact of missing string type in C? - awinter-py
How would the course of history have changed if C had, from the beginning, a safe string type?
======
detaro
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
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.

