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

131–140 of 151 posts

Re: No strcpy either

#131

Post by masklinn »

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?

It has nul-termination for compatibility with C, so you can call c_str and get a C string. With the caveat that an std::string can have nuls anywhere, which breaks C semantics. But C++ does not use that itself.

Re: No strcpy either

#132

Post by School-Cotton »

lesuorac wrote: post #38
Tempest1981 wrote: post #15

Earlier quoted context omitted.

> people are stupid people overestimate AI

Its weird though because looking through the hackone reports in the slop wiki page there aren't actually reproduction steps. It's basically always just a line of code and an explanation of how a function can be mis-used but not a "make a webserver that has this hardcoded response". So like why doesn't the person iterate with the AI until they understand the bug (and then ultimately discover it doesn't exist)? Like ha…

Have you ever had the chance to look at the public-facing support email inbox for a SaaS company? You get absolutely bombarded with these low quality “bug reports” from people trying to farm bounties. They do not care whether the bug is real or impactful, it’s a game of volume for them.

Re: No strcpy either

#133

Post by josefx »

masklinn wrote: post #109
kevin_thibedeau wrote: post #43

Earlier quoted context omitted.

Ignore the prefix and always treat strncpy() as a special binary data operation for an era where shaving bytes on storage was important. It's for copying into a struct with array fields or direct to an encoded block of memory. In that context you will never be dependent on the presence of NUL. The only safe usage with strings is to check for NUL on every use or wrap it. At that point you may as well switch to a new f…

> an era where shaving bytes on storage was important Fixed size strings don’t save bytes on storage tho, when the bank reserves 20 bytes for first name and you’re called Jon that’s 17 bytes doing fuckall. What they do is make the entire record fixed size and give every field a fixed relative position so it’s very easy to access items, move record around, reuse allocations (or use static allocation), … cycles is what…

> Fixed size strings don’t save bytes on storage tho

I have seen plenty of fixed strings in the 8 to 20 byte range, not much, but often enough for a passable identifier. The memory management overhead for a simple dynamically allocated string is probably larger than that even on a 32 bit system.

Re: No strcpy either

#134

Post by loeg »

oneshtein wrote: post #121
loeg wrote: post #104

Earlier quoted context omitted.

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

split_at_mut is just unsafe code (and sibling comment mentioned it hours before you did). The borrow checker doesn't natively understand that.

Re: No strcpy either

#136

Post by saghm »

alexfoo wrote: post #124
saghm wrote: post #95

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

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

I guess to me that seems like pretty big logical leap. It seems equally plausible that they consider C successful and not going anywhere, so they care about improving the way strings are handled (and therefore gave an example of something they would consider better). Your response seems to be trying to defend against an implication that wasn't apparent in what you were responding to, so it wasn't clear at all to me what point you were trying to make.

Re: No strcpy either

#137

Post by saghm »

tialaramex wrote: post #100
saghm wrote: post #93

Earlier quoted context omitted.

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.

Arguably the C ABI was one of those Worse is Better problems like the C language itself. Better languages already existed, but C was basically free and easy to implement, so now there's C everywhere. It seems likely that if not for this ABI we might have an ABI today where all languages which want to offer FFI can agree on how to represent say the immutable slice reference type (Rust's &[T], C++ std::span) Just an ag…

From a historical perspective, my guess is that C interop in some fashion has basically been table stakes for any language of the past few decades, and when you want to plug two arbitrary languages together, if that's the one common API they both speak, it's the most obvious way to do it. I'm not sure I'd consider this "worse is better" as much as just self-reinforcing emergent behavior. I'm not even sure I can come up with any example of an explicitly designed format for arbitrary language interop other than maybe WASM (which of course is a lot more than just that, but it does try to tackle the problem of letting languages interact in an agnostic way).

Re: No strcpy either

#138

Post by Cyph0n »

loeg wrote: post #134
oneshtein wrote: post #121

Earlier quoted context omitted.

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

split_at_mut is just unsafe code (and sibling comment mentioned it hours before you did). The borrow checker doesn't natively understand that.

It is safe btw. The difference is that it returns two mutable references vs. one shared ref and one mutable ref. But as they noted, a mutable ref can always be “downgraded” into a shared ref.

Re: No strcpy either

#139

Post by juliangmp »

String handling (or arrays in general) has got to be the single aspect of C that I despise the most. Its clunky to use, often needs unnecessary copying (e.g. atoi) and makes it really easy to invoke undefined behavior.

I still don't get why a simple ptr+size type hasn't made its way into the language. #embed got in but I guess a new type would have been too much... at least we got bool after a few decades.

Also, for those that want the trimming behavior of strncpy but with the null termination, you can replace the strncpy calls with snprintf. You should also always enable -Wstringop-truncation.

Post reply on HN