Hacker News Reader

Comment by jstimpfle | Hacker News Reader

Except that's a non-sequitur because you can totally keep separate string length fields.

The only NUL that C requires is the NUL following C string literals, and you can even easily define char-arrays without NUL.

    char buf[5] = "Hello";

or even

    #define DEFINE_NONZ_STRING(name, lit) char name[sizeof lit - 1] = lit "";

Can also easily build pointer + length representations, without even a runtime strlen() cost.

    struct String { const char *buf, int len; };
    #define STRING(lit) ((String) { (lit ""), sizeof lit - 1 })

View on HN

What do you do when the strings might have more than MAX_INT characters?

What will you do on your 200th birthday?

In case you're more interested in theory than practice, I have a different answer: I use a different API.

However, I'm aware not even that could stop you, because you could still ask "what do you do when the strings might have more than SIZE_MAX characters?", which is entirely possible (as a combination of 2 or more strings).

And to answer that, we're coming back to my original answer: It doesn't happen. I'm not calling the API with such huge strings. (And no, I usually don't keep formal proofs that it couldn't happen -- there are also an infinite number of other properties that I don't verify).

Yep, and what if I want and to make an arbitrarily large array without much copying?

INT_MAX is often far less than SIZE_MAX (the former is usually the max of a signed 32-bit integer, the latter of an unsigned 64-bit integer), so usually nothing special.

SIZE_MAX is the largest possible value of type size_t. size_t is defined as an unsigned type that is big enough to represent the size of the largest possible object (which basically means the size of the virtual address space i.e. 2^32 on a 32-bit system and usually 2^48 on a 64-bit system, which is being addressed with an uint64_t).

None of that is relevant since you're extremely unlikely to hit either limit by accident. If you really want, you can hit 32-bit limit if you're doing things that snprintf really shouldn't be used for, and likewise you can hit size_t limit if you're on a 32-bit system and joining multiple large strings.

Yes, my point is just that since all the "strn" C string-handling functions in the standard library use a size_t for the size if you've got more than INT_MAX characters there's not necessarily any problem. INT_MAX is pretty much always going to be lower than SIZE_MAX, even on 32-bit systems since the former is signed and the latter isn't. You just call snprintf or whatnot as usual. If you manage to have more than SIZE_MAX characters, then you have a problem. Libc probably can't solve it for you though, since SIZE_MAX has to be large enough to cover any allocation so you have some sort of segmented architecture that the C standard library isn't expecting.

If that is ever a possible issue, you switch the implementation to use two pointers.

    struct String { const char *buf, const char *buf_end; };

Actually I was answering this question wrong because I somehow understood it in the context of snprintf() return int, and I should have just replied "you can switch to size_t if you like". start + end pointer is certainly not necessary, not sure why one would ever do this. It's more inviting of bugs compared to start pointer + length.

It is how many languages implement strings without being bound by numeric limits.

Naturally for this to work out without bugs, it cannot be exposed directly, only manipulated via a string library.

size_t is large enough to hold the size of the largest possible object in memory. In practice, on most architectures, that means it is the same size as pointers. I'm not sure if there is a case where start + end pointer can describe a valid string in memory that start pointer + size couldn't? If that was the case, that string wouldn't be an "object" by definition.

What's the point of the empty string literal "" ?

It's a poor man's assertion that the "lit" is indeed a string literal (such that we can get the string length using sizeof) and not a variable (of pointer type, where sizeof returns the size of the pointer not the string-buffer). If you pass a variable instead of a string literal, that will be a syntax error.

Reply on news.ycombinator.com