5 ms·
Unsafe is a very distinct code smell. Like the hydrogen sulfide added to natural gas to allow folks to smell a gas leak. If you smell it when you're not worki
by timschmidt 2y ago
Unsafe is a very distinct code smell. Like the hydrogen sulfide added to natural gas to allow folks to smell a gas leak.
If you smell it when you're not working on the gas lines, that's a signal.
- cmrdporcupine 2y agoLook, no. Just go read the unsafe block in question. It's just SIMD intrinsics. No memory access. No pointers. It's unsafe in name only. No need to get all moral about it.
- kccqzy 2y agoBy your line of reasoning, SIMD intrinsics functions should not be marked as unsafe in the first place. Then why are they marked as unsafe?
- cmrdporcupine 2y agoThere's no standardization of simd in Rust yet, they've been sitting in nightly unstable for years: https://doc.rust-lang.org/std/intrinsics/simd/index.html https://doc.rust-lang.org/std/intrinsics/simd/index.html So I suspect it's a matter of two things: 1. You're calling out to what's basically assembly, so buyer beware. This is basically FFI into C/asm. 2. There's no guarantee on what comes out of those 128-bit vectors after to follow any sanity or expectations, so... buyer beware. Same reason std::mem::transmute is marked unsafe. It's really the weakest form of unsafe. Still entirely within the bounds of a sane person to reason about.
- pclmulqdq 2y ago> they've been sitting in nightly unstable for years So many very useful features of Rust and its core library spend years in "nightly" because the maintainers of those features don't have the discipline to see them through.
- cmrdporcupine 2y agosimd and allocator_api are the two that irritate me enough to consider a different language for future systems dev projects. I don't have the personality or time to wade into committee type work, so I have no idea what it would take to get those two across the finish line, but the allocator one in particular makes me question Rust for lower level applications. I think it's just not going to happen. If Zig had proper ADTs and something equivalent to borrow checker, I'd be inclined to poke at it more.
- anonymoushn 2y agogeneric simd abstractions are of quite limited use. I'm not sure what's objectionable about the thing Rust has shipped (in nightly) for this, which is more or less the same as the stuff Zig has shipped for this (in a pre-1.0 compiler version).
- cmrdporcupine 2y agoThe issue is that it's sitting in nightly for years. Many many many years. I don't write software targetting nightly, for good reason.
- NobodyNada 2y agoBefore I started working with Rust, I spent a lot of time using Swift for systems-y/server-side code, outside of the Apple ecosystem. There is a lot I like about that language, but one of the biggest factors that drove me away was just how fast the Apple team was to add more and more compiler-magic features without considering whether they were really the best possible design. (One example: adding compiler-magic derived implementations of specific protocols instead of an extensible macro system like Rust has.) When these concerns were raised on the mailing lists, the response from leadership was "yes, something like that would be better in the long run, but we want to ship this now." Or even in one case, "yes, that tweak to the design would be better, but we already showed off the old design at the WWDC keynote and we don't want to break code we put in a keynote slide." When I started working in Rust, I'd want some feature or function, look it up, and find it was unstable, sometimes for years. This was frustrating at first, but then I'd go read the GitHub issue thread and find that there was some design or implementation concern that needed to be overcome, and that people were actively working on it and unwilling to stabilize the feature until they were sure it was the best possible design. And the result of that is that features that do get stabilized are well thought out, generalize, and compose well with everything else in the language. Yes, I really want things like portable SIMD, allocators, generators, or Iterator::intersperse. But programming languages are the one place I really do want perfect to be the enemy of good. I'd rather it take 5+ years to stabilize features than for us to end up with another Swift or C++.
- steveklabnik 2y ago> There's no standardization of simd in Rust yet Of safe SIMD, but some stuff in core::arch is stabilized. Here's the first bit called in the example of the OP: https://doc.rust-lang.org/core/arch/x86/fn._mm_clmulepi64_si128.html https://doc.rust-lang.org/core/arch/x86/fn._mm_clmulepi64_si...
- jandrewrogers 2y agoThe example here is trivially safe but more general SIMD safety is going to be extremely difficult to analyze for safety, possibly intractable. For example, it is perfectly legal to dereference a vector pointer that references illegal memory if you mask the illegal addresses. This is a useful trick and common in e.g. idiomatic AVX-512 code. The mask registers are almost always computed at runtime so it would be effectively impossible to determine if a potentially illegal dereference is actually illegal at compile-time. I suspect we’ll be hand-rolling unsafe SIMD for a long time. The different ISAs are too different, inconsistent, and weird. A compiler that could make this clean and safe is like fusion power, it has always been 10 years away my entire career.
- vlovich123 2y agoPresumably a bounds check on the mask could be done or a safe variant exposed that does that trick under the hood. But yeah I don’t disagree that it’s “safe SIMD” is unlikely to scratch the itch for various applications but hopefully at least it’ll scratch a lot of them enough that the remaining unsafe is reduced.
- fooker 2y agoNo, a bounds check beats the purpose of simd in these cases
- vlovich123 2y agoNot necessarily if you can hoist the bounds check outside of the loop somehow.
- CryZe 2y agoThey are in the process of marking them safe, which is enabled through the target_feature 1.1 RFC. In fact, it has already been merged two weeks ago: https://github.com/rust-lang/stdarch/pull/1714 https://github.com/rust-lang/stdarch/pull/1714 The change is already visible on nightly: https://doc.rust-lang.org/nightly/core/arch/x86/fn._mm_xor_si128.html https://doc.rust-lang.org/nightly/core/arch/x86/fn._mm_xor_s... Compared to stable: https://doc.rust-lang.org/core/arch/x86/fn._mm_xor_si128.html https://doc.rust-lang.org/core/arch/x86/fn._mm_xor_si128.htm... So this should be stable in 1.87 on May 15 (Rust's 10 year anniversary since 1.0)
- thrance 2y agoFor now the caller has to ensure proper alignment of SMID lines. But in the future a safe API will be made available, once the kinks are ironed out. You can already use it in fact, by enabling a specific compiler feature [1]. [1] https://doc.rust-lang.org/std/simd/index.html https://doc.rust-lang.org/std/simd/index.html
- anonymoushn 2y agothere are no loads in the above unsafe block, in practice loadu is just as fast as load, and even if you manually use the aligned load or store, you get a crash. it's silly to say that crashes are unsafe.
- jchw 2y agoWell, there's a category difference between a crash as in a panic and a crash as in a CPU exception. Usually, "safe" programming limits crashes to language-level error handling, which allows you to easily reason about the nature of crashes: if the type system is sound and your program doesn't use unsafe, the only way it should crash is by panic, and panics are recoverable and leave your program in a well-defined state. By the time you get to a signal handler, you're too late. Admittedly, there are some cases where this is less important than others... misaligned load/store wouldn't lead to a potential RCE, but if it can bring down a program it still is a potential DoS vector. Of course, in practice, even in Rust, it isn't strictly true that programs without unsafe can't crash with fatal runtime errors. There's always stack overflows, which will crash you with a SIGABRT or equivalent operating system error.
- exDM69 2y agoThey are marked as unsafe because there are hundreds and hundreds of intrinsics, some of which do memory access, some have side effects and others are arithmetic only. Someone would have to individually review them and explicitly mark the safe ones. There was a bug open about it and the rationale was that no one with the expertise (some of these are quite arcane) was stepping up to do it. (edit: other comments in this thread suggest that this effort is now underway and first changes were committed a few weeks ago) You can do safe SIMD using std::simd but it is nightly only at this point.
- timschmidt 2y agoI don't read any moralizing in my previous comment. And it seems to mirror the relevant section in the book: "People are fallible, and mistakes will happen, but by requiring these five unsafe operations to be inside blocks annotated with unsafe you’ll know that any errors related to memory safety must be within an unsafe block. Keep unsafe blocks small; you’ll be thankful later when you investigate memory bugs." I hope the SIMD intrinsics make it to stable soon so folks can ditch unnecessary unsafes if that's the only issue.
- SkiFire13 2y agoSIMD intrinsics are unsafe because they are available only under some CPU features.
- mrob 2y agoThere's no standard recipe for natural gas odorant, but it's typically a mixture of various organosulfur compounds, not hydrogen sulfide. See: https://en.wikipedia.org/wiki/Odorizer#Natural_gas_odorizers https://en.wikipedia.org/wiki/Odorizer#Natural_gas_odorizers
- timschmidt 2y agoTIL!
- rob74 2y agoTIL also - until today, I thought it was just "mercaptan". Turns out there are actually two variants of that: > Ethanethiol (EM), commonly known as ethyl mercaptan is used in liquefied petroleum gas (LPG) and resembles odor of leeks, onions, durian, or cooked cabbage Methanethiol, commonly known as methyl mercaptan, is added to natural gas as an odorant, usually in mixtures containing methane. Its smell is reminiscent of rotten eggs or cabbage. ...but you can still call it "mercaptan" and be ~ correct in most cases.
- throwaway150 2y ago> Like the hydrogen sulfide added to natural gas to allow folks to smell a gas leak. I am 100% sure that the smell they add to natural gas does not smell like rotten eggs.
- beacon294 2y agoThey add mercaptan which is like 1000x the rotten egg smell of H2S.
- taejo 2y agoMercaptan is a group of compounds, more than one of which are used as gas odorants, so in some places, gas smells of rotten eggs, similar to H2S, while in others gas doesn't smell like that at all, but a quite distinct smell that's reminiscent garlic and durian.
- hyperbrainer 2y agoyou are lucky to not have smelled metacarpan (which is what is actually put in). Much much worse than H2S
- throwaway150 2y agoI have. It's worse no doubt. But it's not the smell of rotten eggs. My comment was meant to be tongue-in-cheek to correct the mistake of saying "H2S" in the GP comment.
- hyperbrainer 2y agoIf that is the case (and I have no reason to believe otherwise), I apologise. Should work on detecting tone better.
- RossBencina 2y agoHydrogen Sulfide is highly corrosive (big problem in sewers and associated infrastructure) I highly doubt you would choose to introduce it to gas pipelines on purpose.
- branko_d 2y agoHydrogen sulfide is highly toxic (it's comparable to carbon monoxide). I doubt anyone in their right mind would put it intentionally in a place where it could leak around humans. But it can occur naturally in natural gas.
- k1t 2y agoI assume GP was referring to mercaptan, or similar. i.e. Something with a distinctive bad smell. https://en.m.wikipedia.org/wiki/Methanethiol https://en.m.wikipedia.org/wiki/Methanethiol
- littlestymaar 2y ago> Hydrogen sulfide is highly toxic (it's comparable to carbon monoxide) It's a bad comparison since CO doesn't smell, which is what makes it dangerous, while H2S is detected by our sense of smell at concentrations much lower than the toxic dose (in fact, its biggest dangers comes from the fact that at dangerous concentration it doesn't even smell anything due to our receptors being saturated). It's not what's being put in natural gas, but it wouldn't be that dangerous if we did.
- gigatexal 2y agoSomeone mentioned to me that for something as simple as a Linked list you have to use unsafe in rust Update its how the std lib does it: https://doc.rust-lang.org/src/alloc/collections/linked_list.rs.html#50-53 https://doc.rust-lang.org/src/alloc/collections/linked_list....
- School-Cotton 2y agoNo you don’t. You can use the standard linked list that is already included in the standard library. Coming up with these niche examples of things you need unsafe for in order to discredit rust’s safety guarantees is just not interesting. What fraction of programmer time is spent writing custom linked lists? Surely way less than 1%. In most of the other 99%, Rust is very helpful.
- vikramkr 2y agoI think the point is that it's funny that the standard library has to use unsafe to implement a data structure that's like the second data structure you learn in an intro to CS class
- Sharlin 2y agoYeah, but Rust just proves the point here that (doubly) linked lists a) are surprisingly nontrivial to get right, b) have almost no practical uses, and c) are only taught because they're conceptually nice and demonstrate pointers and O(1) vs O(n) tradeoffs. Note that safe Rust has no problems with singly-linked lists or in general any directed tree structure.
- School-Cotton 2y agoWhy is it particularly funny? C has to make a syscall to the kernel which ultimately results in a BIOS interrupt to implement printf, which you need for the hello world program on page 1 of K&R. Does that mean that C has no abstraction advantage over directly coding interrupts with asm? Of course not.