[plt-scheme] Eli Barzilay's new FFI stuff

On Sat, 7 Aug 2004 16:50:18 -0400, Eli Barzilay <eli at barzilay.org> wrote:
> On Aug  7, Christopher Armstrong wrote:

> > (super-slot (ptr-ref obj  _super))

> > It's frustrating because I have really long slot and type names, and
> > that I'm duplicating the type-name in the same expression. Should I
> > just suck it up?
> 
> Definitely not!  It's not the names which are a problem -- it's the
> fact that the ptr-ref will copy the contained substructure instance.
> But this is only a problem that is imposed by the pointer tags, which
> is the technical problem I mentioned in the previous email.

Ok, I think I vaguely understand what you just said. :-) So, how can I
solve or work around this problem?

> > > The reason I said "many cases" is that I'm not sure if there can
> > > some alignment problems that will make `foo' have different
> > > layouts if you use:
> >
> > Well, I asked some people knowledgeable in C and they said that
> > there shouldn't be any alignment issues, and that their equivalence
> > is defined by the ANSI standard...? If this is the case, then I
> > definitely don't need any special support in define-cstruct for
> > substructing; this is quite tolerable.
> 
> OK, I'll see if I can hack something quick.

On further discussion with my colleagues, I may be incorrect about
this. While it may be applicable to my current use case, it may not be
a generally good idea.

The problem cited was padding issues - that structs may be padded at
the end, and the padding is platform/compiler dependant. So if your C
code has
typedef struct {
  super SuperStruct;
  int foo;
} FooBar

the location of 'foo' may be different based on padding at the end of
SuperStruct, so! depending on the way that was compiled, or whatever,
(define-cstruct foo-bar ([super _superstruct] [foo _int])) may or may
not have the same in-memory representation. I think that's how it
went, anyway. :-) And I have no idea how you'd solve this in a general
way.

Now, I think (hope) this doesn't matter in *my* case because the
structs that I'm interfacing to actually _don't_ use the C-equivalent
of this technique; instead, they use a CPP define containing all the
members of the struct and say stuff like

typedef struct { 
  SuperStruct_HEAD // There is also an actual SuperStruct, which is
what I'm using
  int foo; 
} FooBar;

So assuming libffi doesn't add any padding to the end of structs, my
interface which uses (define-cstruct foo-bar ([super _superstruct]
[foo _int])) will match up.

[Sigh, now I'm even hearing stuff about how there could be padding
differences even without including other structs. This is frikkin'
depressing. I'll just try to keep doing it the way I'm doing it and
see if I run into problems.]

But anyway, in the case where I _do_ want to do it this way - what
were you talking about hacking something up quick? AIUI no extra
support is necessary in your library for me to do sub-structing in
this way (as I'm already doing it this way without extra support, and
with apparent success :).

> On Aug  7, Christopher Armstrong wrote:
> > I found another problem: I've got a string object struct that
> > defines a string with 'size' and 'val' fields, where the val field
> > is just defined as 'char sval[1];' in the real struct definition.
> 
> You mean that the string is contained in the struct instead of just a
> pointer to it?

Yes.

> > I figured make-sized-byte-string would be the best way to extract
> > the string, but I don't have the pointer to the beginning of the
> > string necessary to pass to that function. Maybe I'm going about
> > this the wrong way, but if I'm not, would it make sense for there to
> > be 'type-slot-pointer' functions generated in addition to the
> > 'type-slot' functions, with define-cstruct? Or maybe I didn't notice
> > some other way to get the pointer to the start of the struct
> > (without doing my own pointer arithmetic...).
> 
> Currently there is no reasonable way to do pointer arithmetic for the
> same reason that a `mystring-sval-pointer' is a bad idea -- it will
> give you a pointer to the middle of an object, but the GC will have
> problems with something like that.

Well, how else can I extract the string from that struct? I admit I
don't understand the interaction between the GC and your FFI; but
isn't it only the scheme-encapsulation of the pointer object returned
from (mystring-sval-pointer mystring) that needs to be GC-watched, not
the actual pointer itself?

-- 
 Twisted | Christopher Armstrong: International Man of Twistery
  Radix  |          Release Manager,  Twisted Project
---------+            http://radix.twistedmatrix.com