Stop using strncpy already (2013) • Hacker News Board

Re: Stop using strncpy already (2013)

#11

Post by jstimpfle » Fri, Aug 31, 2018, 2:13 PM UTC

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

If efficiency is not a concern for you and you rather like the convenience, good for you.

Personally I feel plain const char pointers (plus length, depending on expected size) are good enough to emulate the immutable string type. For modifiable strings, I still prefer viewing them as chunks of memory, using char pointer + length + capacity. Nice thing is, you can easily go from the former to the latter in the lifetime of any one string. You can also pool many strings in large chunks if you build only one string at any one time.

Re: Stop using strncpy already (2013)

#12

Post by jstimpfle » Fri, Aug 31, 2018, 2:24 PM UTC

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/

Strings are so tiny an abstraction over plain memory that every C programmer ends up doing them their own way. And that can be a good thing. I already proposed a couple of ways to represent or muck with strings in my other comment.

Re: Stop using strncpy already (2013)

#13

Post by adrianN » Fri, Aug 31, 2018, 2:31 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…

Whatever alternative reliably prevents buffer overflows, so pretty much anything but char*.

Re: Stop using strncpy already (2013)

#14

Post by hedora » Fri, Aug 31, 2018, 2:35 PM UTC

I don’t understand why silently truncating strings is considered to be acceptable practice.

If you have the length of both, simply assert the length of the destination is <= the length of the source. Problem solved (bugs become obvious in testing).

Re: Stop using strncpy already (2013)

#15

Post by mcguire » Fri, Aug 31, 2018, 2:42 PM UTC

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]”?

Re: Stop using strncpy already (2013)

#16

Post by cliffy » Fri, Aug 31, 2018, 2:44 PM UTC

jstimpfle wrote: post #12

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/

Strings are so tiny an abstraction over plain memory that every C programmer ends up doing them their own way. And that can be a good thing. I already proposed a couple of ways to represent or muck with strings in my other comment.

How is that a good thing? There are ways of abstracting/handling strings that are strictly safer than other ways. In an unsafe language like C, you're inviting problems by trying to do things in your own idiosyncratic way.

Re: Stop using strncpy already (2013)

#17

Post by needlepont » Fri, Aug 31, 2018, 2:48 PM UTC

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

Re: Stop using strncpy already (2013)

#18

Post by kevindqc » Fri, Aug 31, 2018, 2:50 PM UTC

jandrese wrote: post #10

beefhash wrote: post #5

> strlcpy is designed to solve the null-termination problems – it always null-terminates. It’s certainly an improvement over strncpy, however it isn’t natively available in VC++. Let's not forget that it's also not natively available in glibc. Though you'll find it in every BSD you can think of.

Sadly, it still has this braindamage: Like snprintf(3), the strlcpy() and strlcat() functions return the total length of the string they tried to create. For strlcpy() that means the length of src. For strlcat() that means the initial length of dst plus the length of src. So if you've mmaped in something like the OpenStreetMaps xml dump file and try to strlcpy out the first 100 bytes (because you didn't want to have…

"Let's read all the data you don't want because!" nice

Re: Stop using strncpy already (2013)

#19

Post by jstimpfle » Fri, Aug 31, 2018, 2:53 PM UTC

cliffy wrote: post #16

jstimpfle wrote: post #12

Earlier quoted context omitted.

Strings are so tiny an abstraction over plain memory that every C programmer ends up doing them their own way. And that can be a good thing. I already proposed a couple of ways to represent or muck with strings in my other comment.

How is that a good thing? There are ways of abstracting/handling strings that are strictly safer than other ways. In an unsafe language like C, you're inviting problems by trying to do things in your own idiosyncratic way.

Sometimes performance or flexibility are important concerns. But feel free to manage millions of small strings with std::string or even as GC'ed objects :). And incur the overhead of indirection when attaching bounded-size strings to other data.

Re: Stop using strncpy already (2013)

#20

Post by IChooseYou » Fri, Aug 31, 2018, 2:53 PM UTC

gp7 wrote: post #3

Two years after this post, the Linux kernel added strscpy, the api of which is equivalent to the safe strncpy in this post. Internally, it stops copying once it reaches the null terminator. https://lwn.net/Articles/659214/

Also Microsoft's strncpy_s has been around forever.