Hacker News Reader

Comment by hzhou321 | Hacker News Reader

If we preset the end of buffer with '\0' and then assume the buffer having 1-less capacity, wouldn't it address the strncpy issue?

View on HN

Well, again, you have to assume that the caller called you right, i.e. that the pointer you were passed points to a buffer with exactly one zero in it, at the end. Furthermore, unless there's also a (potentially wrong) length argument, you have to read every byte of the destination buffer while you're copying and stop when you see a zero. There's a lot to be said for a reimplementation like bstrlib that wraps char arrays in structs and gives you replacements for most of the string functions, but then you still have all these C APIs to deal with that use char*. And you have the overhead of trying to do things right at runtime. Sibling comment mocks languages that do compile-time safety checking, but I totally see the appeal.

I am not sure I follow the extent of the problem.

With `strncpy`, the caller assumes the responsibility of buffer size (by specify that size explicitly every single time. I thought that responsibility is not being debated within the current context.

That responsibility - for passing the correct buffer size - is one of the issues. I have seen many bugs where the caller simply passed the wrong size to strncpy. If you have a fixed-size buffer then the compiler can infer the size for you, thus making this class of bugs go away entirely.

TL;DR - I've reviewed enough code to know that software developers pass the wrong size to strncpy and friends.

So you need a data structure (or language) that have size embedded in, and the knowledge (and restrictions) of that data structure need to spread to every libraries or function that one use (we are talking about string handling here). It appears to me that you have cornered yourself that the only solution is to modify C/C++ standards to redefine string handling.

I am not saying that is bad. But solutions already exist. One is using the string class, another being transiting to a dynamic language (having size as part of data structure and checking it at every usage is one step into dynamic types).

Alternatively, the compiler can take over this responsibility by statically check every call (the rust solution). That is a different language. On that, I have a question: how can we pass the syntactic buffer size into a static library without embedding the size into the data? If we do embedding the size, then it is still dynamic within the context of the library.

Either way, one should not still be discussing the safety of strncpy here.

Now as long as we are discussing strncpy, I assume it is given that we do not want to have buffer size as permanent part of the simple string type and we are not looking for any solutions that demand an overhaul of the language/libraries. I assume it is given that caller takes the responsibility of buffer size -- exchange with a bit responsibility for simpler system and greater control.

You won't have a good solution (or good discussions) without confining our context first.

You're quite right, it's important to set the context. But no matter what context you pick, your choice is costly:

* We're going to stick with C and its standard library: lots of room to continue to make errors.

* We're going to stick with C, but it's OK to consider an alternate implementation of strings: the C standard, the standard library, and lots of other C libraries are full of functions that deal in char* strings, so you're stuck with them. Also, runtime overhead increases.

* We're willing to consider other languages: other languages have compiler overhead, semantic overhead, runtime overhead, or all three. Also, you still have to interoperate with C.

Even as advocate of mostly safe systems languages I don't see a way of replacing C in the context of UNIX based platforms.

So the main issue is how to make C devs actually adopt some kind of safer C dialect and migrate towards it.

Barely related, I had a good laugh when Ori Bernstein (creator of Myrddin, look them up) was asked, "So, is your language memory safe?". -"No, it's memory dangerous".

I can't quite tell why, but I found it kind of insightful and it made me feel a little better about my own inclination to work on lower levels.

Myrddin looks interesting, thanks for sharing.

And I also find funny the remark. :)

> I thought that responsibility is not being debated within the current context

I bring it up because the article makes programming errors on the part of the caller part of the case for its "safe" solution.

Of course, but everyone wants to overdo the complexity of the time worn solution. OMG you need to null terminate the string after all the _other_ gymnastics..gee C sure does suck! Why don't we use rust|go|c++ ad-nauseam. bzero(buf,sz); /memset nazis here/ strncpy(buf,src,sz - 1);

It doesn't make sense to have to null-terminate the string by hand (maybe) after doing a "safe" STRING copy. Which means it's easy to forget to do and that's a dangerous wart in the design.

Really, stop using C. To quote Hayao Miyazaki, C was a mistake.

What I meant is more like:

    #define BUFSIZE 100
    char buf[BUFSIZE+1]
    buf[BUFSIZE]=0 // for global var, it is already zeroed, right?

Then one can call strncpy(buf, BUFSIZE, ...) without worrying about null-termination.

Reply on news.ycombinator.com