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

41–50 of 83 posts

Re: Stop using strncpy already (2013)

#41

Post by bitwize »

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

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.

Re: Stop using strncpy already (2013)

#42

Post by iforgotpassword »

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.

Nonsense, strncpy and friends are just fi2•∟1F↔Ñ

Re: Stop using strncpy already (2013)

#43

Post by hzhou321 »

sevensor wrote: post #25
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 ar…

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.

Re: Stop using strncpy already (2013)

#44

Post by adiusmus »

iforgotpassword wrote: post #42
pcwalton wrote: post #32

Earlier quoted context omitted.

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.

Nonsense, strncpy and friends are just fi2•∟1F↔Ñ

Looks like a Perl script I read once.

Re: Stop using strncpy already (2013)

#45

Post by coldtea »

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.

In what way could ever that be a "good thing" over having 2-3 implementations of strings in the standard library that cover 99% of the different ways and trade-offs, and which each has a method to convert a string to any of the others?

Re: Stop using strncpy already (2013)

#46

Post by coldtea »

jstimpfle wrote: post #19
cliffy wrote: post #16

Earlier quoted context omitted.

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.

Rust manages to do it just fine...

Re: Stop using strncpy already (2013)

#48

Post by brucedawson »

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_safe is a template function, not a macro. That immediately makes it orders of magnitude better than you were claiming.

I agree that a standard fix for this would be great. It's been five years since I wrote the post, the solution has been available for many years longer than that, and the standards committee has shown no interest in fixing this issue. In the interim I think it would be irresponsible for developers to continue using strncpy or any of the other unsafe options when strcpy_safe is so simple and effective.

Re: Stop using strncpy already (2013)

#49

Post by brucedawson »

bitwize wrote: post #40
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?

strcpy_s is a good option for those cases where the appropriate response to having too long an input string is terminating the program. However it is a poor choice when continuing execution is desired.

Re: Stop using strncpy already (2013)

#50

Post by kodis »

I'd say "Stop using C and C++ already" or "Stop using null terminated strings already", but I recognize that those are not always practical solutions.

I do have some maintainability concerns though about the promulgation of numerous competing home-brew solutions to a near trivial problem throughout a code base.

Post reply on HN