If I recall correctly, all structs are already packed under the eZ80 C ABI because the eZ80 is an 8-bit processor with no alignment requirements. So adding the packed attribute shouldn't change sizeof for any of the structs on eZ80.
If it did somehow change the size of the structs, that would cause ABI breakage with the usbdrvce library implementation, which is written in assembly and isn't looking at the header file.
Do you have example code that has an incorrect struct size with the current header file?

@commandblockguy That makes a lot more sense. I don't have any proof that the size is incorrect when using sizeof(), just that seeing visual studio code report the wrong size calculation when hovering over variables and such threw me off. For peace of mind I went in myself and added attribute((packed)) to not only get the right size but to satisfy my assumption that the ez80 wouldn't always handle those structures without any arbitrary byte alignment. I don't know why I thought that adding that to the header would make a difference, obviously the header isn't compiled in the final binary.

I guess the only other reason to add that in would to be let people interested in learning about USB structures know that these structures must have no byte padding but there's plenty of information out there that definitely already says that so, eh.

While I'm here, do you happen to know if I can code a libload library in C and how I would set that up using the toolchain? Any information I can find on a guide or some kind of template would be great. If I need to open up a discussion I definitely will.

There's not currently an easy way to write a library in C. A few people have made C libraries by manually pasting the assembly code the compiler outputs (removing the linker directives) into an assembly file in-tree for the toolchain, but that's not a recommended or officially supported workflow.
Out of curiosity, what use case do you have in mind for the library? A lot of the time statically-linked libraries make more sense on the CE than libload-based shared libraries because of the relatively tight RAM constraints.

Ever since I started to understand how to use usbdrvce, I had an interest in seeing if I could communicate with iPhones in recovery/dfu/wtf/port dfu mode.

The inspiration came from libimobiledevice, specifically libirecovery, in which I wanted to create a lightweight version of it and control some apple products from my calculator, because...why not??

I've also always been super interested in "hacking" iDevices; jailbreaks, pwndfu, downgrades, etc., so this was something that I thought would be really cool, to make my own little library for it. I don't know the slightest bit of assembly so I knew my only option would be to try to write it in C.

I got it working pretty nicely. I followed the path of the actual library (which used libusb and IOKit) and just "translated" it to fit with what usbdrvce gave me and it worked. It could reboot my iPhone 3G, iPhone 4, iPhone SE, and my 16 Pro...just not the M1 Macs, probably since the power doesn't work that way for them, i dont know.

Here's the video that I so professionally recorded showing it off.
https://github.com/user-attachments/assets/82eafadd-9c45-4804-8ae3-0d68c0cad22a