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

121–130 of 151 posts

Re: No strcpy either

#121

Post by oneshtein »

loeg wrote: post #104
Cyph0n wrote: post #103

Earlier quoted context omitted.

Do you mean borrows for different fields of a struct? If so, that’s handled today - it’s sometimes called “splitting borrows”: https://doc.rust-lang.org/nomicon/borrow-splitting.html

Not exactly -- independent subranges of the same range (as would be relevant to something like memcpy/memmove/strcpy). E.g., https://godbolt.org/z/YhGajnhEG It's mentioned later in the same article you shared above.

  fn f() {
    let mut v = vec![1, 2, 3, 4, 5];
    let (header, tail) = v.split_at_mut(1);
    b(&header[0], &mut tail[0]);
  }

Re: No strcpy either

#122

Post by zabzonk »

throwaway2037 wrote: post #117
masklinn wrote: post #74

Earlier quoted context omitted.

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.

Doesn't C++'s std::string also use a null terminated char* string internally? Do you count that also?

Since C++11 it is required to be null-terminated, you can access the terminator with (for e.g.) operator[], and the string can contain non-terminator null characters.

Re: No strcpy either

#123

Post by amluto »

adrian_b wrote: post #112
amluto wrote: post #108

Earlier quoted context omitted.

Modern x86 CPUs have actual instructions for strcpy that work fairly well. There were several false starts along the way, but the performance is fine now.

They have instructions for memcpy/memmove (i.e. rep movs), not for strcpy. They also have instructions for strlen (i.e. rep scasb), so you could implement strcpy with very few instructions by finding the length and then copying the string. Executing first strlen, then validating the sizes and then copying with memcpy if possible is actually the recommended way for implementing a replacement for strcpy, inclusive in t…

Whoops, this proves I’m not really a userspace assembly programmer…

But you can indeed safely read past the end if a buffer if you don’t cross a page boundary and you aren’t bound by the rules of, say, C.

Re: No strcpy either

#124

Post by alexfoo »

saghm wrote: post #95
alexfoo wrote: post #55

Earlier quoted context omitted.

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…

> 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. Even with the premise that sales of software is a good metric for analyzing design of the language (which I think is arguable at best), we don't know that even more money might have been made with better strings in C. You coming justify pretty much anything with that…

That wasn't really the point I was making.

It was more a response to the OP's comment of:

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

Which, to me, sounded like it was a surprise that anything written in C could be a success at all given that something as basic as the string handling (which is pretty fundamental) is bordering on useless.

As I put in my other comment, there were plenty of reasons way back in the 80s/90s why C was chosen for a lot of software, and hardly any (if any at all) of those reasons remain nowadays.

> MongoDB (which indicentally is on C++ and presumably makes plenty of use of std::string) made millions of dollars despite having the bug you mention, so why bother fixing it?

Again, that's not the point I was making, no-one said anything about not fixing something because of how much money it has made.

All it comes down to is that a lot of very successful software is very shoddily written, in a variety of languages, not just notoriously memory-unsafe languages like C. Well written software, or software written in a "better" language, might have a better chance of "succeeding" (whatever that means), but that doesn't mean that awful software can't succeed.

Re: No strcpy either

#125

Post by [deleted] »

saghm wrote: post #93
masklinn wrote: post #74

Earlier quoted context omitted.

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.

Given that the C ABI is basically the standard for how arbitrary languages interact, I wouldn't characterize all of the headaches this can cause as just when other languages interact with C; arguably it can come up when any two languages interact at all, even if neither are C.

[deleted]

Re: No strcpy either

#126

Post by delaminator »

BobbyTables2 wrote: post #97
Someone wrote: post #70

Earlier quoted context omitted.

> I've always wondered at the motivatons of the various string routines in C This idiom: char hostname[20]; ... strncpy( hostname, input, 20 ); hostname[19]=0; exists because strncpy was invented for copying file names that got stored in 14-byte arrays, zero terminated only if space permitted ( https://stackoverflow.com/a/1454071 )

It’s also horrible because each project ends up reinventing their own abstractions or solutions for dealing with common things. Destroys a lot of opportunity for code reuse / integration. Especially within a company. Alternatively their code base remains a steaming pile of crap riddled with vulnerabilities.

That's how everything works. You start off with some atomics and build up from there. Things that people like get standardized, And before you know what's going on it's called stdlib.

It took a decade between Stroustrup's 1985 book "The C++ Programming Language" and the STL proposed and accepted by the ANSI/ISO committee in 1994.

Re: No strcpy either

#127

Post by smeeagain2 »

BobbyTables2 wrote: post #96
thayne wrote: post #81

Earlier quoted context omitted.

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.

The standard C library can’t even manipulate NUL terminated strings for common use cases… Simple things aren’t simple - want to append a formatted string to an existing buffer? Good luck! Now do it with UTF-8! I truly feel the standard library design did more disservice to C than the language definition itself.

[dead]

Re: No strcpy either

#128

Post by spacechild1 »

ahoka wrote: post #99
swinglock wrote: post #14

I'm surprised curlx_strcopy doesn't return success. Sure you could check if dest[0] != '/0' if you care to, but that's not only clumsy to write but also error prone, and so checking for success is not encouraged.

Yeah, thought the same. Expect some CVEs in the future.

What kind of CVE would you expect? The destination buffer will always contain a valid null-terminated string (as long as the buffer size is not zero).

Re: No strcpy either

#129

Post by jcranmer »

jandrese wrote: post #71
dingi wrote: post #47

Earlier quoted context omitted.

Isn't strlcpy the safer solution these days?

I don't think anybody in this thread read the article. Strlcpy tries to improve the situation but still has problems. As the article points out it is almost never desirable to truncate a string passed into strXcpy, yet that is what all of those functions do. Even worse, they attempt to run to the end of the string regardless of the size parameter so they don't even necessarily save you from the unterminated string ca…

> Is it really too late for the C committee to not develop a modern string library that ships with base C26 or C27? I get that they really hate adding features, but C strings have been a problem for over 50 years now, and I'm not advocating for the old strings to be removed or even deprecated at this time. Just that a modern replacement be available and to encourage people to use them for new code.

The next version of C (C2y) is expected to be C29, not C26 or C27. And work has been done on a new string library: see, e.g. https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3306.pdf (not the only proposal!). That said, I would be surprised if anything gets merged into the standard in less than a decade, simply because the committee is not organizationally set up for major library overhauls like this.

Re: No strcpy either

#130

Post by trollbridge »

snvzz wrote: post #63
trollbridge wrote: post #9

Earlier quoted context omitted.

Making a strcpy honeypot doesn’t sound like a bad idea… void nobody_calls_me(const char *stuff) { char *a, *b; const size_t c = 1024; a = calloc(c); if (!a) return; b = malloc(c); if (!b) { free(a); return; } strncpy(a, stuff, c - 1); strcpy(b, a); strcpy(a, b); free(a); free(b); } Some clever obfuscation would make this even more effective.

That got those Core SDI abo vibes. Flashback of writing exploits for these back in high school.

In an interesting way, this is an attempt to exploit LLMs into revealing themselves.
Post reply on HN