Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stop using strncpy already (2013)

randomascii.wordpress.com

Post reply on HN
Print view View original

31–40 of 83 posts

Re: Stop using strncpy already (2013)

#31

Post by brucedawson »

hedora wrote: post #14

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

What about user input, strings coming from files, and in general the diversity of things that can go wrong when your product ships. This is particularly important if your product is attacked by those who would like to exploit it.

Asserts are necessary, but not sufficient.

Re: Stop using strncpy already (2013)

#32

Post by pcwalton »

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.

Re: Stop using strncpy already (2013)

#33

Post by yarosv »

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

The author states

> The focus of this post is on fixed-size string buffers, but the technique applies to any type of fixed-length buffer.

Re: Stop using strncpy already (2013)

#34

Post by quietbritishjim »

needlepont wrote: post #27
quietbritishjim wrote: post #24

Earlier quoted context omitted.

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.

What example? Are you confusing me with GP commenter perhaps?

Re: Stop using strncpy already (2013)

#35

Post by iamthad »

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/

strscpy seems like a nice interface. Is an implementation outside of the kernel available? Preferably one that is permissively-licensed?

Also, it doesn't appear to be specified what happens if the count argument is too large to be represented as a ssize_t. The destination buffer would have to be extremely large, so it probably doesn't happen in practice, but it'd be good to specify it, or at least explicitly state it's unspecified / undefined.

https://www.kernel.org/doc/htmldocs/kernel-api/API-strscpy.h...

Re: Stop using strncpy already (2013)

#36

Post by ndesaulniers »

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/

I've had patches rejected from the Linux kernel that tried to switch away from strncpy in favor of strlcpy. The behavior that strncpy continues to zero out the rest of the destination in the case where size of source is less than destination was being relied upon to not leak uninitialized memory to userspace. Seems strscpy alone suffers the same.

Re: Stop using strncpy already (2013)

#37

Post by russdill »

hedora wrote: post #14

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

Because the API is stupid and not intuitive. It's for memory buffers where the string is either NULL terminated or it is the length of the memory buffer. This saves an extra byte. yay?

Re: Stop using strncpy already (2013)

#38

Post by russdill »

russdill wrote: post #37
hedora wrote: post #14

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

Because the API is stupid and not intuitive. It's for memory buffers where the string is either NULL terminated or it is the length of the memory buffer. This saves an extra byte. yay?

I'll add that it's really handy for that specific situation as it also avoids leaking uninitialized bytes.

Re: Stop using strncpy already (2013)

#39

Post by lmm »

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/

Unfortunately C doesn't have a widely accepted dependency/build manager either.

Re: Stop using strncpy already (2013)

#40

Post by bitwize »

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/

strcpy_s, anyone?
Post reply on HN