3 ms·

> I have been working on some software in Rust recently that needs bit and byte manipulation, and we have "unsafe" everywhere and hugely complicated spaghetti c

> I have been working on some software in Rust recently that needs bit and byte manipulation, and we have "unsafe" everywhere and hugely complicated spaghetti compared to the equivalent code in C. I'm curious what makes this so different from my experience. I rarely ever have to write "unsafe", and I'm writing quite low-level engine code that certainly uses bit manipulation. In fact, crates like bitflags and fixedbitset make it so easy that I tend to get dinged in code reviews for using bit flags when structs of booleans would be simpler :)

eru 2y ago
> I'm curious what makes this so different from my experience. I rarely ever have to write "unsafe", and I'm writing quite low-level engine code that certainly uses bit manipulation. Perhaps your usecase is similar enough to eg JavaScript engines? Because that's a usecase that browser writers would at least have in mind?
- Ygg2 2y ago
  It's not. It's Bevy. What effects this is separating your unsafe into unsafe abstractions. If you're careful you don't have to write too much unsafe. Granted it's not easy.
  - pclmulqdq 2y ago
    A game engine is much more similar to a browser engine than you think. The operations you have discussed, using bits as flags, are also the most basic forms of binary-level manipulation out there. Things like tagged pointers and bit flags fit nicely and neatly into an encapsulated unsafe abstraction (provided you want to add an extra 1000 lines of code for it). As far as I can tell, any time you want to rely on the exact binary layout of something in memory, you need unsafe. As a corollary, any time you want to bit cast from one type to another, you need unsafe. This means that things like succinct data structures and building network protocols need quite a bit of unsafe everywhere. The former needs you to do things like "store 14 bits of X here and 12 bits there..." The latter needs control of bit and byte layout because you want to carefully eliminate implementation-defined compiler behavior.
    - CryZe 2y ago
      Take a look into bytemuck or zerocopy. I haven't used unsafe when doing byte level manipulation in a long time.
    - Ygg2 2y ago
      And a jet engine and IC engine are engines, but putting your car engine into a Boeing and vice versa would be an unwise decision. I'd argue you're over-abstracting the differences. They have different purposes. Game engines need high performance, while browsers need to enable wide selection of APIs.
      - pclmulqdq 2y ago
        Browsers need very high performance, too.
        Ygg2 2y ago
        To be fair to my analogy, both ICE and Jet engines need high RPMs too, and pull power but not on the same level. Browsers layout and rendering will have some elements similar to that of a game, but it isn't on the same level. A game can usually assume that it's trusted to run that shader, in a browser that's a vector for attack. Security design will impact game engines and browsers differently. Granted, people are doing their darnedest to make games in the lowest common denominator technology, i.e. Electron.
        eru 2y ago
        C was designed to write Unix, but they didn't overfit it for that very specific case only. So it has seen application elsewhere. Neither was Rust overfitted to exactly only writing browser engines.
      - eru 2y ago
        > And a jet engine and IC engine are engines, but putting your car engine into a Boeing and vice versa would be an unwise decision. Sure, but you'd expect the design software for a car engine to be at least half-way relevant for a jet engine in a pinch. Compared to eg the software an architect would use to design a bridge.

eru 2y ago

> I'm curious what makes this so different from my experience. I rarely ever have to write "unsafe", and I'm writing quite low-level engine code that certainly uses bit manipulation. Perhaps your usecase is similar enough to eg JavaScript engines? Because that's a usecase that browser writers would at least have in mind?

Ygg2 2y ago
It's not. It's Bevy. What effects this is separating your unsafe into unsafe abstractions. If you're careful you don't have to write too much unsafe. Granted it's not easy.
- pclmulqdq 2y ago
  A game engine is much more similar to a browser engine than you think. The operations you have discussed, using bits as flags, are also the most basic forms of binary-level manipulation out there. Things like tagged pointers and bit flags fit nicely and neatly into an encapsulated unsafe abstraction (provided you want to add an extra 1000 lines of code for it). As far as I can tell, any time you want to rely on the exact binary layout of something in memory, you need unsafe. As a corollary, any time you want to bit cast from one type to another, you need unsafe. This means that things like succinct data structures and building network protocols need quite a bit of unsafe everywhere. The former needs you to do things like "store 14 bits of X here and 12 bits there..." The latter needs control of bit and byte layout because you want to carefully eliminate implementation-defined compiler behavior.
  - CryZe 2y ago
    Take a look into bytemuck or zerocopy. I haven't used unsafe when doing byte level manipulation in a long time.
  - Ygg2 2y ago
    And a jet engine and IC engine are engines, but putting your car engine into a Boeing and vice versa would be an unwise decision. I'd argue you're over-abstracting the differences. They have different purposes. Game engines need high performance, while browsers need to enable wide selection of APIs.
    - pclmulqdq 2y ago
      Browsers need very high performance, too.
      - Ygg2 2y ago
        To be fair to my analogy, both ICE and Jet engines need high RPMs too, and pull power but not on the same level. Browsers layout and rendering will have some elements similar to that of a game, but it isn't on the same level. A game can usually assume that it's trusted to run that shader, in a browser that's a vector for attack. Security design will impact game engines and browsers differently. Granted, people are doing their darnedest to make games in the lowest common denominator technology, i.e. Electron.
        eru 2y ago
        C was designed to write Unix, but they didn't overfit it for that very specific case only. So it has seen application elsewhere. Neither was Rust overfitted to exactly only writing browser engines.
    - eru 2y ago
      > And a jet engine and IC engine are engines, but putting your car engine into a Boeing and vice versa would be an unwise decision. Sure, but you'd expect the design software for a car engine to be at least half-way relevant for a jet engine in a pinch. Compared to eg the software an architect would use to design a bridge.