Hacker News Reader

Comment by hedora | Hacker News Reader

I haven't seen anyone actually use the strn* functions correctly, but I have seen correct uses of the str* variants.

Put another way, the following either maintains the string invariant and does not silently truncate out, or it fails on a null pointer dereference. If you forget the + 1, it will certainly fail in valgrind when out is used, and will almost certainly crash your unit tests.

size_t len = strlen(in)+1;

char* out = malloc(len);

memcpy(out, in, len);

Open challenge: Produce something that is correct (i.e., it cannot silently corrupt the string), is as simple, and is less error prone with the strn* functions.

View on HN

I'd argue sds meets that challenge, though not in the way you probably mean: https://github.com/antirez/sds/blob/master/README.md

The challenge is to do it with the strn* functions. :-)

String manipulation isn't that hard, and strcpy and friends aren't very good. I'm a fan of creating a struct that has a uint8_t* and a length, and using that for all buffers, including strings.

Thanks for the pointer though! I'll definitely give it a careful read.

> I'm a fan of creating a struct that has a uint8_t* and a length, and using that for all buffers, including strings.

Unsurprisingly, "record strings" are what most every language even just slightly higher-level than C does: C++, Rust, Swift, Go, …

Your code will only work if malloc() pads with 0s. Otherwise it will be missing the null character at the end of the out string. So I would switch it to calloc() which is guaranteed to pad with 0s. Or use memset to set it all to 0s.

It copies the null from the input string. It maintains the string invariant without silently corrupting data.

Writing C code with well-defined semantics in the face of existing heap corruption is harder. The strn* functions don't do that either though.

The code copies the origin string up to and including the null terminator, which must exist as strlen was used to obtain the size.

It doesn't copy the null terminator because it's using memcpy. It's only copying the string without the null byte.

I think you are missing the +1 behind the call to strlen. strlen reports the number of chars before the zero-byte, adding one includes it.

I go back and forth between putting the +1 on the first line, or repeating it in the other lines. Putting it on the first line is harder to screw up, but harder to read.

For real programs you basically have to put it in the initial computation, or it will be forgotten somewhere later (maybe in a later commit).

> Putting it on the first line is harder to screw up, but harder to read.

Mayhaps "len" should be renamed to something clearer?

Reply on news.ycombinator.com