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

141–150 of 151 posts

Re: No strcpy either

#141

Post by loeg »

Cyph0n wrote: post #138
loeg wrote: post #134

Earlier quoted context omitted.

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.

The implementation is unsafe, as I said:

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

https://doc.rust-lang.org/src/core/slice/mod.rs.html#2086

Re: No strcpy either

#142

Post by Cyph0n »

loeg wrote: post #141
Cyph0n wrote: post #138

Earlier quoted context omitted.

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.

The implementation is unsafe, as I said: > split_at_mut is just unsafe code (and sibling comment mentioned it hours before you did). The borrow checker doesn't natively understand that. https://doc.rust-lang.org/src/core/slice/mod.rs.html#2086

No, that’s the unchecked version. Two people are telling you that this method exists and is safe, so I am not sure why you’re still doubting this lol.

Re: No strcpy either

#143

Post by bmandale »

Cyph0n wrote: post #142
loeg wrote: post #141

Earlier quoted context omitted.

The implementation is unsafe, as I said: > split_at_mut is just unsafe code (and sibling comment mentioned it hours before you did). The borrow checker doesn't natively understand that. https://doc.rust-lang.org/src/core/slice/mod.rs.html#2086

No, that’s the unchecked version. Two people are telling you that this method exists and is safe, so I am not sure why you’re still doubting this lol.

The checked variant just calls the unchecked, and the panicking variant calls the checked variant. They all need to call unsafe code. See here for details: https://doc.rust-lang.org/nomicon/borrow-splitting.html

Re: No strcpy either

#144

Post by skirge »

Sharlin wrote: post #31
Scubabear68 wrote: post #7

From the article: > It has been proven numerous times already that strcpy in source code is like a honey pot for generating hallucinated vulnerability claims This closing thought in the article really stood out to me. Why even bother to run AI checking on C code if the AI flags strcpy() as a problem without caveat?

Because these people who run AI checks on OSS code and submit bogus bug reports either assume that AIs don't make mistakes, or just don't care if the report is legit or not, because there's little to no personal cost to them even if it isn't.

even stupid report may give you invites to private programs

Re: No strcpy either

#145

Post by Cyph0n »

bmandale wrote: post #143
Cyph0n wrote: post #142

Earlier quoted context omitted.

No, that’s the unchecked version. Two people are telling you that this method exists and is safe, so I am not sure why you’re still doubting this lol.

The checked variant just calls the unchecked, and the panicking variant calls the checked variant. They all need to call unsafe code. See here for details: https://doc.rust-lang.org/nomicon/borrow-splitting.html

Then you misunderstand what unsafe means in Rust. Every single Rust binary needs to eventually call unsafe code at some layer of the callstack.

Is creating a TCP socket using stdlib functions unsafe? How about writing to a file? Or acquiring a mutex?

I would suggest doing some more reading before chiming in here :)

Re: No strcpy either

#146

Post by BobbyTables2 »

delaminator wrote: post #126
BobbyTables2 wrote: post #97

Earlier quoted context omitted.

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.

Yeah but those standard libraries are still inadequate 30 years later.

Imagine a hypothetical Python scenario where every application and library had their own list implementations with differently named methods and behavior.

Yet C is exactly that. Is it not common place to log messages to a file? How many applications and code bases DO NOT use syslog(). And if one wants to use syslog, then assert failures won’t get logged there…

Sure, with a custom assertion and logging framework one can get reasonable behavior. But it’s not automatic. Hence, a Tower of Babel …

Re: No strcpy either

#147

Post by delaminator »

BobbyTables2 wrote: post #146
delaminator wrote: post #126

Earlier quoted context omitted.

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.

Yeah but those standard libraries are still inadequate 30 years later. Imagine a hypothetical Python scenario where every application and library had their own list implementations with differently named methods and behavior. Yet C is exactly that. Is it not common place to log messages to a file? How many applications and code bases DO NOT use syslog(). And if one wants to use syslog, then assert failures won’t get…

That's Linux C you're talking about. Many, many, many C codebases don't use syslog.

Re: No strcpy either

#148

Post by BobbyTables2 »

delaminator wrote: post #147
BobbyTables2 wrote: post #146

Earlier quoted context omitted.

Yeah but those standard libraries are still inadequate 30 years later. Imagine a hypothetical Python scenario where every application and library had their own list implementations with differently named methods and behavior. Yet C is exactly that. Is it not common place to log messages to a file? How many applications and code bases DO NOT use syslog(). And if one wants to use syslog, then assert failures won’t get…

That's Linux C you're talking about. Many, many, many C codebases don't use syslog.

Exactly!

At least Python has a standardized “logging” module where applications can control the format and destination.

But with the standard C library, there is little common ground. Solutions to the same basic problems are constantly reinvented - differently.

Re: No strcpy either

#149

Post by bmandale »

Cyph0n wrote: post #145
bmandale wrote: post #143

Earlier quoted context omitted.

The checked variant just calls the unchecked, and the panicking variant calls the checked variant. They all need to call unsafe code. See here for details: https://doc.rust-lang.org/nomicon/borrow-splitting.html

Then you misunderstand what unsafe means in Rust. Every single Rust binary needs to eventually call unsafe code at some layer of the callstack. Is creating a TCP socket using stdlib functions unsafe? How about writing to a file? Or acquiring a mutex? I would suggest doing some more reading before chiming in here :)

You have totally misunderstood what the person you are talking with means by unsafe. Perhaps you should resolve that prior to such condescensions.

Re: No strcpy either

#150

Post by Gibbon1 »

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

I remember some story that early on they thought function calls had little overhead and so used lots of little functions. And then found that actually no they were spending a lot of time doing function calls. But turned out no one cared.

To me the string library looks like small snippets of early leet C code hoisted into a library.

Post reply on HN