Stop using strncpy already (2013) • Hacker News Board

Re: Stop using strncpy already (2013)

#61

Post by hzhou321 » Fri, Aug 31, 2018, 5:55 PM UTC

needlepont wrote: post #17

hzhou321 wrote: post #9

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?

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);

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.

Re: Stop using strncpy already (2013)

#62

Post by pjmlp » Fri, Aug 31, 2018, 6:38 PM UTC

jstimpfle wrote: post #11

umvi wrote: post #6

I feel like there are a lot of good alternatives to C. What we did on our team was get our C compiling under g++, and then refactor as C++14. Now string copies are trivial and safe. I'm sure it would have been even safer to switch to Rust or something, but no one in my company has any experience with that, while there were a few C++ gurus.

What are the good alternatives? You can either copy memory manually, or have a system like C++'s that causes lots of tiny allocations, which is very inefficient. Both in space and time. You can also opt for immutable strings to be able to share strings more conveniently and efficiently, at the cost of O(n^2) build time (where automatic optimizations fail) or decreased convenience (explicit string-stream aka string bu…

You care about that after a profiler proves that it is actually a problem to the expected delivery SLAs for the application.

Micro-optimizing each line of C code based on gut feeling is not an option if quality matters.

Re: Stop using strncpy already (2013)

#63

Post by pjmlp » Fri, Aug 31, 2018, 6:42 PM UTC

sevensor wrote: post #58

hzhou321 wrote: post #53

Earlier quoted context omitted.

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 exis…

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* stri…

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.

Re: Stop using strncpy already (2013)

#64

Post by jstimpfle » Fri, Aug 31, 2018, 6:48 PM UTC

pjmlp wrote: post #62

jstimpfle wrote: post #11

Earlier quoted context omitted.

What are the good alternatives? You can either copy memory manually, or have a system like C++'s that causes lots of tiny allocations, which is very inefficient. Both in space and time. You can also opt for immutable strings to be able to share strings more conveniently and efficiently, at the cost of O(n^2) build time (where automatic optimizations fail) or decreased convenience (explicit string-stream aka string bu…

You care about that after a profiler proves that it is actually a problem to the expected delivery SLAs for the application. Micro-optimizing each line of C code based on gut feeling is not an option if quality matters.

It's not about the code, but about choice of data structure. Unfortunately that has to be planned ahead to some degree. You can't really optimize it after the fact. Typically a choice affects more than a single line of code, but that doesn't mean "microoptimizing every line of code", which is obviously a bad idea.

Re: Stop using strncpy already (2013)

#65

Post by bigpicture » Fri, Aug 31, 2018, 7:37 PM UTC

brucedawson wrote: post #52

ahoka wrote: post #8

strncp is fine, however it was never meant for null-terminated strings! A safe alternative is using snprintf and checking the return value for truncation.

snprintf is hardly safe. It does guarantee null termination, so that is progress, but it requires the caller to pass the buffer size. As I mention in the "More typing means more errors" section of the article software developers are endlessly creative about ways to pass the wrong buffer size. They usually pass the right buffer size, but 99.9% correct still means a lot of bugs. These bugs can be avoided by using a tem…

> These bugs can be avoided by using a template function to infer the destination buffer size

I'm a big fan of using strategies to avoid bugs. Another strategy than can be a big help is to spend a little time thinking about what kinds of strings you are going to be using and how big they might be. And then sanitizing your program input based on those sizes. Find the too-long strings before they get into your program and before you start copying them around.

The system I'm responsible for came into being as a set of programs on a Univac II and was a bunch of C and FORTRAN when I joined. Because of the need to pass data between C and FORTRAN programs/code, we had a set of 10-20 standard string sizes, based on what kind of text you had. We no longer write new code in either C or FORTRAN, but maintain the concept of standard sizes for our text. By specifying the kind of text (we also do this with numbers) in the design steps, we save far more time and effort than we spend over the entire SDLC.

Re: Stop using strncpy already (2013)

#66

Post by brucedawson » Fri, Aug 31, 2018, 7:54 PM UTC

mcguire wrote: post #15

Been a while since I used C++... How does this work if the size of the destination isn't known at compile time? I.e., it's not "buffer[5]”?

You get a compile error.

And this is progress. I have fixed code that looked something like this:

    strncpy(dst, sizeof(dst), src);
    data[sizeof(dst)-1] = 0;

See the bug? Of course not, because it's not visible, but I've seen this pattern used where dst is a pointer. This means that four or eight bytes (three or seven if you don't count the null terminator) gets copied, regardless of how many bytes dst points to. With strcpy_safe an attempt to copy to dst would not work and the developer would have to fix their code.

Every mistake that can be made, will be made.

Re: Stop using strncpy already (2013)

#67

Post by [deleted] » Fri, Aug 31, 2018, 7:56 PM UTC

pjmlp wrote: post #63

sevensor wrote: post #58

Earlier quoted context omitted.

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* stri…

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.

[deleted]

Re: Stop using strncpy already (2013)

#68

Post by jstimpfle » Fri, Aug 31, 2018, 7:58 PM UTC

pjmlp wrote: post #63

sevensor wrote: post #58

Earlier quoted context omitted.

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* stri…

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.

Re: Stop using strncpy already (2013)

#69

Post by pjmlp » Fri, Aug 31, 2018, 8:32 PM UTC

jstimpfle wrote: post #68

pjmlp wrote: post #63

Earlier quoted context omitted.

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. :)

Re: Stop using strncpy already (2013)

#70

Post by astrodust » Fri, Aug 31, 2018, 8:57 PM UTC

pcwalton wrote: post #32

AdmiralAsshat wrote: post #7

In principle, I feel like "Ignore the language-provided standard libraries and use this little macro I wrote in all your code" is bad advice. If the standard libs are that bad , the community should really lobby for the inclusion of a "safe" string copy into the C standard. Failing that, use a battle-tested third-party library like bstrlib[0]. [0] http://bstring.sourceforge.net/

The C standards committee is incredibly conservative, only adding new features if absolutely necessary. Unless the composition and goals of the committee drastically change, a new standard string API will never happen. If you must write C, you should use a real string library, and not string.h.

They should have a superset of the C standard for writing "secure C", as is important in some kernel or application code.