Stop using strncpy already (2013) • Hacker News Board

Re: Stop using strncpy already (2013)

#21

Post by mikeash » Fri, Aug 31, 2018, 2:53 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/

What choice do you have? “Fix the standard” is ideal, but few programmers have the luxury of waiting a decade for the fix to happen and become available in all their target compilers.

Re: Stop using strncpy already (2013)

#22

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

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.

https://lwn.net/Articles/225108/

Re: Stop using strncpy already (2013)

#23

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

That is trusting user input. You don't do that, right?

Re: Stop using strncpy already (2013)

#24

Post by quietbritishjim » Fri, Aug 31, 2018, 3:02 PM UTC

needlepont wrote: post #23

jandrese wrote: post #10

Earlier quoted context omitted.

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…

That is trusting user input. You don't do that, right?

It's not about trusting user input. It's asking for a function to create a 100 byte substring of a very long string and expecting it to take time~100 not time~len(src).

In fairness, that is probably just not the target "market" for strlcpy. Presumably, it is meant for "please copy this whole string which I expect to fit in the target (but catch me in the rare case that it does not)".

Re: Stop using strncpy already (2013)

#25

Post by sevensor » Fri, Aug 31, 2018, 3:05 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?

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.

Re: Stop using strncpy already (2013)

#26

Post by tedunangst » Fri, Aug 31, 2018, 3:11 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…

Don't treat mmapped files as strings.

Re: Stop using strncpy already (2013)

#27

Post by needlepont » Fri, Aug 31, 2018, 3:21 PM UTC

quietbritishjim wrote: post #24

needlepont wrote: post #23

Earlier quoted context omitted.

That is trusting user input. You don't do that, right?

It's not about trusting user input. It's asking for a function to create a 100 byte substring of a very long string and expecting it to take time~100 not time~len(src). In fairness, that is probably just not the target "market" for strlcpy. Presumably, it is meant for "please copy this whole string which I expect to fit in the target (but catch me in the rare case that it does not)".

As you note: your example is specious.

Re: Stop using strncpy already (2013)

#28

Post by jandrese » Fri, Aug 31, 2018, 3:24 PM UTC

quietbritishjim wrote: post #24

needlepont wrote: post #23

Earlier quoted context omitted.

That is trusting user input. You don't do that, right?

It's not about trusting user input. It's asking for a function to create a 100 byte substring of a very long string and expecting it to take time~100 not time~len(src). In fairness, that is probably just not the target "market" for strlcpy. Presumably, it is meant for "please copy this whole string which I expect to fit in the target (but catch me in the rare case that it does not)".

It does trust the user input. If you are being attacked and the input has lost its null terminator then your strlcpy might core dump even if it doesn't leak data.

They made it this way to make it more of a drop-in replacement for strncpy, but IMHO they should have changed the return value to be the number of characters copied. If your return value is less than n, then your string was copied completely, if it is equal to n then your string was truncated.

There are good reasons to use strlcpy over memcpy. For example you have a text parser where the most common case is each string is only a few bytes long, but you need to be able to handle odd cases where they are much longer. So you have a large buffer that you only use a tiny chunk of most times. With strlcpy it will be quick, but memcpy will be chugging the whole buffer each time.

Re: Stop using strncpy already (2013)

#29

Post by wmil » Fri, Aug 31, 2018, 3:24 PM UTC

I feel like all of these articles can be summed up with:

"C strings and string functions aren't designed to be safe. If you want safe strings use a library."

Re: Stop using strncpy already (2013)

#30

Post by brucedawson » Fri, Aug 31, 2018, 3:25 PM UTC

IChooseYou wrote: post #20

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.

It's too bad strncpy_s is so unwieldy to use. Having to pass the TRUNCATE flag is frustrating. I really want a two argument (dst, src) function that guarantees null termination.