So for padding, it sometimes depends on how your compiler works, but usually, it doesn’t pack bytes by default - that needs to manually be done. Otherwise, a uint32 followed by 2 uint16s, for example, will take up the space for 3 uint32s (in a 32-bit native compiler). If you manually specify packing (implemented differently depending on your compiler and such), then it will pack those all properly into just 2 uint32s.

I do imagine 24 bits followed by 16 more in a bit field for a 32-bit number would potentially cause problems. But it’s late here and I could certainly be wrong so take that with a grain of salt.

That also said, I typically don’t use bitfields directly in structures - it’s not usually good practice, at least where I work. I’d either do a uint8[3] or use a whole uint32 that is a union, and in the union would be your :24 followed by a reserved : 8, if that makes any sense. It’s sometimes worth it to leave a few extra bytes in there just from an organization standpoint.

Out of curiosity, what’s wrong with medium? (Serious question)

It kinda looks like a marigold to me. If the leaves are crunchy, it’s underwatered. There’s a chance that some of it is still alive so you may see some small growth start to pop up - but usually, everything that’s crunchy is totally dead. If it’s mushy or limp, it’s underwatered - which unfortunately is probably worse.

Congrats! Looking wonderful :)

I’d personally be super surprised if they were outsourcing their firmware engineering - but I do suppose it’s technically possible.

Ahh, yeah. Neither would I. I would expect my USB sticks to last longer than that, lol.

That aside - here’s a fun fact. We sell the NAND from scrapped SSDs that we no longer need for development to a third-party vendor that actually desolders it and uses it for flash drives. So… you never really know what kinda flash storage you get on your flash drives! (Or… we did do this, until the program recently got shuttered because NAND is so damn cheap now)

I do agree with the plastic brick part - but there is actually reasoning behind that second part - the read-only mode. That happens when the flash is down to a very low amount of life left (usually predetermined by the manufacturer). It is by design because the flash will degrade further if you continue to write to it, so by forcing it to read-only mode, users can still recover their data in a failing/aging SSD. Not to say it isn’t a huge pain in the ass when that happens though, lol

These failures don’t have to do with where they’re manufactured - it seems like this is some sort of firmware bug. NAND doesn’t really just choose to wipe itself at random. Actual NAND chip failures are few and far-between, so this is very likely much more than a hardware issue.

That said, I personally have done a lot of testing with WD-manufactured NAND, compared other companies’ NAND - and the WD NAND is pretty crap. I can’t really go into further details than that, though.

Source - I’m an SSD firmware engineer.

To be fair. Google does own nest. So the nest hub is also a google product. But yes… different products from different entities - not a great comparison

Best of luck!!