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

No strcpy either

daniel.haxx.se

Post reply on HN
Print view View original

81–90 of 151 posts

Re: No strcpy either

#81

Post by thayne »

masklinn wrote: post #74
amelius wrote: post #62

Earlier quoted context omitted.

We should just move away from null-terminated strings, where we can, as fast as we can.

We have. C is basically the only langage in any sort of widespread use where terminated strings are a thing. Which of course causes issues when languages with more proper strings interact with C but there you go.

We should move away from it in C usage as well.

Ideally, the standard would include a type that packages a string with its length, and had functions that used that type and/or took the length as an argument. But even without that it is possible avoid using null terminated strings in a lot of places.

Re: No strcpy either

#82

Post by bluecalm »

alexfoo wrote: post #55
t43562 wrote: post #18

I've always wondered at the motivatons of the various string routines in C - every one of them seems to have some huge caveat which makes them useless. After years I now think it's essential to have a library which records at least how much memory is allocated to a string along with the pointer. Something like this: https://github.com/msteinert/bstring

Yet software developed in C, with all of the foibles of its string routines, has been sold and running for years with trillions of USD is total sales. A library that records how much memory is allocated to a string along with the pointer isn't a necessity. Most people who write in C professionally are completely used to it although the footgun is (and all of the others are) always there lurking. You'd generally just…

>>(It's also very easy to get this wrong, I almost wrote `hostname[20]=0;` first time round.)

Impossible to get wrong with a modern compiler that will warn you on that or LSP that will scream the moment you type ; and hit enter/esc.

Re: No strcpy either

#83

Post by tptacek »

manwe150 wrote: post #76
ahoka wrote: post #57

"strncpy() is a weird function with a crappy API." Well if you bother looking up that it's originally created for non null-terminated strings, then it kinda makes sense. The real problem begun when static analyzers started to recommend using it instead of strcpy (the real alternative used to be snprintf, now strlcpy).

strlcpy is a BSD-ism that isn't in posix. The official recommendation is stpecpy. Unfortunately, it is only implemented in the documentation, but not available anywhere unless you roll your own: https://man7.org/linux/man-pages/man7/string_copying.7.html

Who cares? Just vendor it into your project. It's a tiny string manipulation function.

(I agree with the author of the piece that strlcpy doesn't actually solve the real problem.)

Re: No strcpy either

#84

Post by bentley »

manwe150 wrote: post #76
ahoka wrote: post #57

"strncpy() is a weird function with a crappy API." Well if you bother looking up that it's originally created for non null-terminated strings, then it kinda makes sense. The real problem begun when static analyzers started to recommend using it instead of strcpy (the real alternative used to be snprintf, now strlcpy).

strlcpy is a BSD-ism that isn't in posix. The official recommendation is stpecpy. Unfortunately, it is only implemented in the documentation, but not available anywhere unless you roll your own: https://man7.org/linux/man-pages/man7/string_copying.7.html

strlcpy is in POSIX now, actually.

https://pubs.opengroup.org/onlinepubs/9799919799/functions/s...

Re: No strcpy either

#85

Post by bentley »

tourist2d wrote: post #66
ahoka wrote: post #57

"strncpy() is a weird function with a crappy API." Well if you bother looking up that it's originally created for non null-terminated strings, then it kinda makes sense. The real problem begun when static analyzers started to recommend using it instead of strcpy (the real alternative used to be snprintf, now strlcpy).

Your comment makes no sense. If it was designed for non-null terminated strings, why would it specifically pad after a null terminator? I looked up the actual reason for its inception: --- Rationale for the ANSI C Programming Language", Silicon Press 1990. 4.11.2.4 The strncpy function strncpy was initially introduced into the C library to deal with fixed-length name fields in structures such as directory entries. Su…

“fixed-length name fields in structures such as directory entries”

“the trailing null is unnecessary for a maximum-length field”

That is a non–null terminated string.

Re: No strcpy either

#86

Post by manwe150 »

bentley wrote: post #84
manwe150 wrote: post #76

Earlier quoted context omitted.

strlcpy is a BSD-ism that isn't in posix. The official recommendation is stpecpy. Unfortunately, it is only implemented in the documentation, but not available anywhere unless you roll your own: https://man7.org/linux/man-pages/man7/string_copying.7.html

strlcpy is in POSIX now, actually. https://pubs.opengroup.org/onlinepubs/9799919799/functions/s...

Ah, good point. I forgot it had just gotten added. Past context https://news.ycombinator.com/item?id=36765747

Re: No strcpy either

#87

Post by manwe150 »

samshine wrote: post #79
Tharre wrote: post #53

It's worth noting that strcpy() isn't just bad from a security perspective, on any CPU that's not completely ancient it's bad from a performance perspective as well. Take the best case scenario, copying a string where the precise length is unknown but we know it will always fit in, say, 64 bytes. In earlier days, I would always have used strcpy() for this task, avoiding the "wasteful" extra copies memcpy() would make…

I haven't seen a strcpy use a scalar loop in ages. Is this an ARM thing?

The spec and some sanitizers use a scalar loop (because they need to avoid mistakenly detecting UB), but real world libc seem unlikely to use a scalar loop.

Re: No strcpy either

#88

Post by snickerbockers »

arka2147483647 wrote: post #73
kccqzy wrote: post #48

Earlier quoted context omitted.

You don’t do that by accident. Fixed-width strings are thoroughly outdated and unusual. Your mental model of them is very different from regular C strings.

Sadly, all the bug trackers are full of bugs relating to char*. So you very much do those by accident. And in C, fixed width strings are not in any way rare or unusual. Go to any c codebase you will find stuff like: char buf[12]; sprintf(buf, "%s%s", this, that); // or strcat(buf, ...) // or strncpy(buf, ...) // and so on..

Thats only really a problem if this and that are coming from an external source and have not been truncated. I really don't see this as any more significant of a problem than all the many high level scripting languages where you can potentially inject code into a variable and interpret it.

There are certainly ways in which the c library could've been better (eg making strncpy handle the case where the source string is longer than n) but ultimately it will always need to operate under the assumption that the people using it are both competent and acting in good faith.

Re: No strcpy either

#89

Post by pama »

saagarjha wrote: post #11
pama wrote: post #3

Congrats on the completion of this effort! C/C++ can be memory safe but take some effort. IMHO the timeline figure could benefit in mobile from using larger fonts. Most plotting libraries have horrible font size defaults. I wonder why no library picked the other extreme end: I have never seen too large an axis label yet.

Removing strcpy from your code does not make it memory safe.

Apologies. I never meant to imply that of course. It is a long and arduous process, and this is but a single tiny step.

Re: No strcpy either

#90

Post by masklinn »

tourist2d wrote: post #66
ahoka wrote: post #57

"strncpy() is a weird function with a crappy API." Well if you bother looking up that it's originally created for non null-terminated strings, then it kinda makes sense. The real problem begun when static analyzers started to recommend using it instead of strcpy (the real alternative used to be snprintf, now strlcpy).

Your comment makes no sense. If it was designed for non-null terminated strings, why would it specifically pad after a null terminator? I looked up the actual reason for its inception: --- Rationale for the ANSI C Programming Language", Silicon Press 1990. 4.11.2.4 The strncpy function strncpy was initially introduced into the C library to deal with fixed-length name fields in structures such as directory entries. Su…

> If it was designed for non-null terminated strings, why would it specifically pad after a null terminator?

Padded and terminated strings are completely different beasts. And the text you quote tells you black on white that strncpy deals in padded strings.

Post reply on HN