Re: Interesting C header translation problem
Hi, Honestly, I don't know. I would go stab the original API designers in the face and tell them to clean up their mess. I'm sorry to reply to a 2-year-old topic, but as the original API designer, I simply couldn't resist :) Please do not stab me in the face. The nanopb API was never designed to be wrapped, or to be used as a dynamic library. The situation in the targeted embedded systems is that everything is compiled by the same compiler, under same settings, to a single binary. The packed attribute on enums in GCC makes them use the smallest integer type, uint8_t in this case. All this has been replaced with simpler typedef and #defines nowadays though. As for what was being tried to do in this thread, I would think a native protobuf implementation for D would be much saner than trying to wrap a C implementation. -- Petteri
Re: Interesting C header translation problem
On Tue, 30 Oct 2012 11:05:28 +0100
Alex Rønne Petersen 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:
Re: Interesting C header translation problem
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
a...@lycus.org
http://lycus.org
