Hacker News Reader

Comment by ajross | Hacker News Reader

Not really. C was an iconoclast even at the time. Pascal was the en vogue language of the moment, and it used a length-prefixed string format.

But sure: it's true that in (a half century of!) hindsight, C strings were probably a mistake. But don't sell null-terminated strings short either. C could play tricks that Pascal couldn't. Iterating over the characters of a string has a natural expression using the same compiler features as arrays. A pointer into the middle of a string was still a valid string. You could lex a string inline during parsing by adding termination to the end markers or whitespace, etc...

View on HN

So you just don't store the array's length near the arrays beginning but instead inside the slice-typed variable which lives somewhere else entirely. Boom, you got the best of the both worlds: trivial slicing and reliable bounds checking.

> instead inside the slice-typed variable which lives somewhere else entirely.

OK... where? Now you have a complicated heap-like semantic inside your compiler internals. But not everyone wants their string metadata in the heap. So now you need allocator semantics a-la C++, which ultimately leads to move semantics, etc...

Good luck getting that done in 1972. No, DMR was right, Pascal was wrong, and fancy modern string semantics were still two decades in the future. C was the best it could be given the constraints of the era.

> OK... where?

In the automatic storage, duh, where everybody else puts them today.

> But not everyone wants their string metadata in the heap.

Exactly, so you don't put them there, which is what I am proposing: instead of putting the string length before, or the null delimiter after, the string itself, you put it near the pointer that points to the beginning of the (sub)string.

> you put it near the pointer that points to the beginning of the (sub)string.

And now you have a "string pointer" which is distinct from a "data pointer". You can't allocate a heap block and "put a string in it" because the special thing at the start needs to go with the pointer and not the data in the block. And your 1970's compiler on your PDP-11 with 48kb of RAM needs to manage that. Good luck to you.

Again, we're not answering the question "Can a better string implementation than C be designed?". Clearly the answer is yes. Go pick your favorite, there are literally dozens. We're asking "What else should Richie have done with C that would have been better?". And... it's not what you're suggesting for sure.

> And now you have a "string pointer" which is distinct from a "data pointer". You can't allocate a heap block and "put a string in it" because the special thing at the start needs to go with the pointer and not the data in the block.

The second sentence doesn't follow from the first one.

    struct string {
        char   (*ptr)[static len];
        size_t len;
    };

    struct string new_copy = { .ptr = malloc(100), .len = 100; };
    new_copy = strcpy(new_copy, "some other string"); // string literal is a syntactic sugar for statically allocated 'struct string' with 'ptr' set to an unnamed, statically allocated char[] buffer inside it, and proper 'len' field.

    struct string strcpy(struct string dest, struct string src) {
        struct string result = { .ptr = dest.ptr, .len = min(dest.len, src.len) };
        memcpy(result.ptr, src.ptr, result.len);
        return result;
    }

Or you can do

    struct string *new_copy = malloc(100 + sizeof(struct string));
    new_copy->ptr = (char*)(new_copy + 1);
    new_copy->len = 100;

if you really want to. Just don't pass naked "char*" around, that thing has no obvious extent.

That's C, though. You're writing C. DMR gave you that, in 1972. (Actually not, because you had to wait for structs, but you know what I mean).

But what you seem to be asking for is support in the language for strings that work like this. And that causes problems because of that special handle you've invented. Now strings aren't arrays anymore, they can't have pointers taken to them, they can't have substrings in a natural way, they can't live in ordinary POD memory as a unified thing.

All of which is totally solvable in the runtime of a language written in 2003 or whenenver. But not on a PDP-11.

Pascal strings had the same size overhead as C strings. One using the "byte" for length, the other for size.

But C strings could at least be arbitrarily long, Pascal strings were extremely handicapped. It’s like they understood why length prefix is better, but then picked the worst possible implementation.

Pascal strings were a bad implementation of general strings, but were extraordinarily easy to implement.

screens were generally 80 characters wide 256 was good enough, if you needed to go bigger null terminated could still be done in pascal, you just had to roll your own.

The editors I wrote back in the eighties were just linked lists of pascal strings so a line was limited to 256 characters but these were very fast in VMS and DOS

Also we only had a few character sets and you could live your whole life in ASCII

And worse for pascal, a 256 byte limit on the length and api shenanigans so that not every string allocated needed to consume all that memory if the string itself was shorter.

Reply on news.ycombinator.com