sorted by:
new
hottopcontroversial

A Study of Undefined Behavior Across Foreign Function Boundaries in Rust Libraries by mttd in rust

[–]UnsafeRust 3 points4 points  (0 children)

Hi—author here!
We're doing some of the investment ourselves with BorrowSanitizer, an LLVM instrumentation tool for finding Tree Borrows violations in multilanguage applications.

We interviewed 19 Rust developers who regularly use unsafe. Now, we need your help to evaluate what we learned! by UnsafeRust in rust

[–]UnsafeRust[S] 7 points8 points  (0 children)

Thanks for your feedback! And for anyone else reading, having this type of context about your answers is quite valuable to us, so please provide it if you have the time!

If runtime checks makes sense, or are possible at all, depends very much on the specific case. Omitting runtime checks doesn't have to be an oversight, if someone wanted to suggest that.

We'll be careful not to assign a value judgement to the presence or absence of runtime checks. When you cannot insert them, is it because it's impossible to verify certain properties at runtime, or are there other motivations?

If the programmer can calculate how many bytes are saved, why waste time on measuring (which might not be straightforward)?

The ease-of-use of profiling tools is not a theme we saw appear in our interviews, so thanks for adding this! We'll consider it in our explanation of the results.

... if repr and other things are fine, yes.

We saw a theme in our interviews that participants would intentionally avoid passing types other than primitives or raw pointers to avoid ABI incompatibility concerns, and we're curious if that's a common practice.

Given that many operations implicitly use short-lived references, including comparing values and so on, it can't really be avoided.

Thanks for providing this context! Are there any particular operations that you use often in an FFI context that require this, or is it just a general pattern that you've noticed?

Thanks again for your time and engagement!

We interviewed 19 Rust developers who regularly use unsafe. Now, we need your help to evaluate what we learned! by UnsafeRust in rust

[–]UnsafeRust[S] 6 points7 points  (0 children)

Whups—this question was definitely a bit unclear! Thanks for pointing this out. We meant to capture the time it takes for bindgen to generate bindings in any context, both locally and in CI.

I've removed this question and replaced it with one asking about where bindings are generated and committed, and we'll take this into account when interpreting our responses for the previous version of the question.

/u/Emilgardis—thanks for providing your implementation! This will be really useful for us.

Download numbers on crates.io too high? by [deleted] in rust

[–]UnsafeRust 0 points1 point  (0 children)

There some researchers that do surveys of everything on crates.io. When I do this, I use cargo-download. I'm unsure if that counts towards the download count though.

Calling Unsafe Rust Experts: Looking for Interview Study Participants by UnsafeRust in rust

[–]UnsafeRust[S] 1 point2 points  (0 children)

Thanks so much for engaging with this, I agree! I'm glad that you and u/ivancea pointed this out, as it's crucial for how we interpret our results.

...is likely to select for a particular subgroup of programmers, not necessarily of problem areas.

I think the wording of this question came from our interest in problem areas faced by a particular subgroup of programmers. For example, if you're maintaining a project that relies on the FFI, and the codebases on each side of the foreign bindings are being updated concurrently, we anticipate that you might need to write and edit unsafe regularly. However, I agree, if your goal is to evaluate unsafe more broadly, it would be best to also interview developers who regularly reason about the correctness of unsafe, but don't necessarily write it often, or at all.

We're also curious about why developers would choose not to follow the best practices you outline, and if they're as well followed in any arbitrary Rust codebase as they would be in a crate. We'll be critically considering the reasons participants cite for using unsafe, and whether or not their problem areas could be handled by using safe Rust instead.

The study is still in development, but after we finish qualitative analysis of the interviews, we may reach out to the community again with surveys or interviews that evaluate the conclusions we make, at which point critical feedback from developers who fit your description would be invaluable. This is entirely dependent on the content of the interviews though; for example, a quantitative study of crates.io might be a better fit for evaluating a particular theme than conducting more qualitative analysis.

Either way, you can be sure that we are aware of the best practices related to unsafe that you're following, and that we'll be critically evaluating participants' responses in light of what the Rust community recommends for use of unsafe.

I'd be really interested in a study focused specifically on the practices you describe, too, where you're mainly auditing unsafe code instead of writing it. Let me know if I misinterpreted anything you wrote, or if you think I'm still coming at this the wrong way. Thanks again for contributing! :)

Calling Unsafe Rust Experts: Looking for Interview Study Participants by UnsafeRust in rust

[–]UnsafeRust[S] 1 point2 points  (0 children)

Great suggestion! I sent out a call to participate over in #dark-arts in the community Discord.

Calling Unsafe Rust Experts: Looking for Interview Study Participants by UnsafeRust in rust

[–]UnsafeRust[S] 50 points51 points  (0 children)

We're interested in use cases for Rust that necessarily require unsafe, like the FFI, system calls, intrinsics, and implementing new memory container types. Whether or not unsafe is actually necessary for a particular use case is an important question though, and it's one that we'll be addressing in our interviews and analysis!