Interesting C header translation problem

[Nick Sabalausky]

On Tue, 30 Oct 2012 11:05:28 +0100
Alex Rønne Petersen <alex at 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.