On Tue, 30 Oct 2012 11:05:28 +0100 Alex Rønne Petersen <a...@lycus.org> wrote:
> On 30-10-2012 10:41, Nick Sabalausky wrote: > > Came across this: > > > > #ifdef __GNUC__ > > #define PACKED __attribute__((packed)) > > #else > > #define PACKED > > #endif > > > > typedef enum { > > // Lots o' stuff > > } PACKED my_enum_t; > > > > typedef struct { > > // Lots o' stuff > > const void *ptr; > > } PACKED my_struct_t; > > > > There are a handful of interesting (read: annoying ;) ) problems > > that are (*ahem*) packed into that: > > > > 1. Totally different ABI based on whether or not the **C** side was > > compiled with a GNU compiler. > > Absolutely fucking horrible API design. These matters are, if > anything, related to the system ABI, not the compiler ABI. Making the > layout depend on the compiler ABI makes any sort of sane > interoperability with the API from non-C languages virtually > impossible to do reliably. > Yea, sounds like the best thing after all is to just say "Just don't compile the C side that way." > > > > 2. How to do conditional "align(1)" with minimal ugliness. > > I can't think of anything that doesn't involve repetitive code or > mixins. But worse than that, it's not like you can detect what > compiler was used to build some random library..... > It would require repeating or mixing in the entire body wouldn't it? I didn't think there was any way to mixin just an attribute or otherwise get the same effect, but thought I'd check. > [snip #3-6] I see, thanks. > > > > > For the moment, my "solution" is to just include a note saying > > "Don't compile the *.c files with __GNUC__ defined" ;) But what > > would be the best realistic way to handle these issues? Any > > established practices? > > > > Honestly, I don't know. I would go stab the original API designers in > the face and tell them to clean up their mess. > lol :) I think this one was actually designed to be usable in low-end microcontrollers (nanopb: <http://koti.kapsi.fi/jpa/nanopb/>), so that explains a lot of it. And by binding it to...well, anything but asm...I'm probably in highly-unanticipated waters anyway. I guess I could look for one that's easier to bind with and less obsessive-compulsive about small-size, but I liked that this one does zero dynamic memory allocation unless you're explicit about it.