> actually an incredibly common, totally everyday problem encountered by tens of thousands of developers everyday I never said they're umcommon. As I said, I u

> actually an incredibly common, totally everyday problem encountered by tens of thousands of developers everyday I never said they're umcommon. As I said, I user them all the time. They're incredibly common in specific fields. There are many systems programmers who barely ever use them. There are a lot of footguns with bitfields in C. (1) they know nothing about defaults, (2) they have no way of restricting values beyond bitwidth, (3) they are often inefficient, producing multiple load-modify-stores for what is really a single operation, (4) they are not endian portable. svd2rust addresses all of those: (1) it knows what the defaults are and you can tell it to load them for you, (2) it will restrict the values for each field to only those that are valid (you can use unsafe to bypass the check), (3) it produces a single load-modify-store (or less) for any given operation, (4) it produces shifts and masks internally so doesn't depend on the compiler to behave as expected. Of course, C bitfields don't require tooling, and I'd say they're a little easier to use. It's a trade-off, and I personally prefer the rust side. > I don't think that requiring third-party tooling to implement something so basic is a suitable solution to this problem. Don't most people auto-generate bitfields, too? Like sure, writing a couple by hand is fine, but I didn't think that's typical. > What if the manufacturer of the device I'm working with hasn't released an SVD file? What if I'm not actually working on an MCU at all, but a peripheral driver? You can write your own SVD, or write yaml and convert that to SVD. I think that would probably work for a peripheral driver, too.