[aninhumer]

My feeling is that the clearest way to do this would be:

    self.0.stack_index = stack_index;

using an appropriate packed struct/union type such that this makes sense.

This best represents what you're actually doing, instead of faffing around with bit twiddling to achieve the same result.

Does Rust not allow something like this?

[burfog]

This is indeed a rust failing. There are no untagged unions.

There should be. Obviously, unions with pointers are special. Some code might need to be marked unsafe. I suspect there is a subset of pointer-in-union operations that could be made safe, possibly either changing or using the pointer but not both.

Another thing missing is bifields. I'd love to see this done right, with adjustable packing so that one can use them to write an emulator or file parser.

[steveklabnik]

Bitfields are in a crate, untagged unions are in the RFC process.

[burfog]

Crates and cargo look like trouble:

I'm not going to develop while connected to the internet. This is not allowed by any employer that cares about security.

I prefer to use the package manager that comes with my OS. Every other installer (firefox, nvidia crap, etc.) risks screwing things up.

Given the two things above, I hope you can see how much of a pain it would be to run some non-standard installer. I'd need to ask IT to mirror the rust cargo stuff... and is this even possible? Would I have to dig deep into the rust stuff to change a public key?

With it being a crate, I worry about it going unsupported. I've seen this all too often with firefox extensions. If not that, maybe somebody will come along and change the API.

I couldn't even find the crate. I found one called bitflags that does 1-bit fields. That isn't suitable. I'm looking for something that can handle stuff like an x86-64 descriptor table (GDT, LDT, IDT) entry or a PowerPC opcode. The PowerPC mtspr and bl instructions are interesting examples: mtspr has a 10-bit split bitfield, with a pair of 5-bit halves in the wrong order, and bl has a field that kind of has the low 2 bits stolen by other fields. The x86-64 descriptors have lots of strange-sized split fields and they are tagged unions for which the tag layout is hardware-defined. Another good one is page table entries, from the perspective of: emulator, hypervisor, OS.

With this not being part of the language proper, I have to wonder how well it performs. Has anybody compared the resulting assembly code?

[steveklabnik]

  > I'm not going to develop while connected to the internet.

You don't have to. If you do use crates from crates.io, then you need to be connected the first time, to get everything. Not after that.

   > ... and is this even possible?

Running your own registry with your own universe of crates is very possible. Mirroring the external world inside that one is not that easy.

  > I couldn't even find the crate. ... that isn't suitable.

Well, multi-bit fields are made up of one-bit fields... if you're looking for GDT, LDT, IDT stuff, the crate referenced in the article already has all of that defined for you. If you want to define it yourself, well, I did it with a struct and a method that handles the bit shifting.

  > I have to wonder how well it performs.

Well, Rust is itself implemented in Rust, the standard library is all in Rust, so.

Also, finally, you don't have to use crates.io to use Cargo. You can just specify crates that are on your local filesystem, or a git repository hosted anywhere.