www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Interesting C header translation problem

reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
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.

2. How to do conditional "align(1)" with minimal ugliness.

3. WTF does it even mean to have a packed enum?

4. Having a pointer at the end of a packed struct is asking for trouble
according to D's docs ("The garbage collector assumes that pointers and
references to gc allocated objects will be on size_t byte boundaries.
If they are not, undefined behavior will result.") Probably nothing
that can be done about this one, though, other than just expect the
user to be careful.

5. From what I can gather from GCC and DMD docs, it sounds like
__attribute__((packed)) means:

    align(1) struct my_struct_t{
        align(1):
        // blah, blah, members
    }

BUT, are there any other...ummm..."fun" surprises that could pop up and
need to be taken into account?

6. The easy one: I'm pretty sure "const void *ptr" translates to
"const(void)* ptr", right?

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?
Oct 30 2012
next sibling parent =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <alex lycus.org> writes:
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.
 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.....
 3. WTF does it even mean to have a packed enum?

Nothing.
 4. Having a pointer at the end of a packed struct is asking for trouble
 according to D's docs ("The garbage collector assumes that pointers and
 references to gc allocated objects will be on size_t byte boundaries.
 If they are not, undefined behavior will result.") Probably nothing
 that can be done about this one, though, other than just expect the
 user to be careful.

More generally, a pointer that is not aligned on a 4-byte (on 32-bit systems) or 8-byte (on 64-bit systems) boundary will not be picked up by the GC. This can happen in many situations, e.g.: struct S { align (1): byte b; int* p; byte b; byte b; int* p; } And many other possible layouts. The best way to deal with terrible APIs in this regard is to use GC.addRoot() to keep such pointers alive. This does of course mean that you have to use GC.removeRoot() to make it collectable again...
 5. From what I can gather from GCC and DMD docs, it sounds like
 __attribute__((packed)) means:

      align(1) struct my_struct_t{
          align(1):
          // blah, blah, members
      }

 BUT, are there any other...ummm..."fun" surprises that could pop up and
 need to be taken into account?

It only implies the inner align, not the outer one. GCC has an aligned attribute on variables that can be used to get the effect of the outer one. But no, no real surprises or gotchas here.
 6. The easy one: I'm pretty sure "const void *ptr" translates to
 "const(void)* ptr", right?

Yep.
 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. -- Alex Rønne Petersen alex lycus.org http://lycus.org
Oct 30 2012
prev sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Tue, 30 Oct 2012 11:05:28 +0100
Alex R=F8nne Petersen <alex 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. =20

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=20 mixins. But worse than that, it's not like you can detect what compiler was used to build some random library..... =20

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.
=20
 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=20 the face and tell them to clean up their mess. =20

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.
Oct 30 2012