Mailing List Archive

Interfacing with C structs, enums, etc.
After many months of neglect, I may be able to get back to work on my Wcl to
perl interface. One of the things I will need to do is provide some way for
the perl code to access massive numbers of different callback info structs
and massive numbers of the various widget convenience functions, etc. It
would sure be nice to construct all these interfaces automagically.

I know there has been some work on this, but I haven't really kept track of
things too well, and I apologize in advance for asking questions I probably
ought to know the answers to:

* Where do I find the existing work that has already been done to interface
with structs? Is it already part of 5.002beta1? Or can I ftp it from
somewhere?

* What is the preferred mechanism for providing perl code with access to
structs? Do people use a pack/unpack type approach, or do you make the
struct look like a hash? Or do you just provide get and put functions
for each field? How do you approach nested structs? How about unions?

* I know it is probably impossible to make a mechanism that will work with
any existing C code without being at least as complex as a full blown C
compiler. Has anyone considered adding a "perl" target to gcc which could
compile arbitrary C or C++ code into a perl XS module that provides access
to all the data structures, enums, and functions?

* Another source of (hopefully) accurate information about the layout of
structs is the symbolic debug information that compilers generate. There
are an awful lot of different kinds of debug info from BSD stabs, to AT&T
COFF, to ELF and DWARF versions 1 and 2, to probably many other formats I
don't know about, but perhaps a perl interface to debug info could be
defined and various modules implemented to read different kinds of debug
info (perhaps even, the code to do this could be extracted from gdb, which
already knows how to read different kinds of debug info). Is this an idea
worth pursuing? [.I certainly know a lot about reading COFF and DWARF2
having written all the object reader code for our debugger here :-)].

* I don't know much about CORBA other than the acronym and a vague notion
of what the project is trying to do, but it seems to me that they have
similar interface issues to deal with, and perhaps there is some CORBA
work that perl code take advantage of to interface to other languages.
Has anyone who knows more about CORBA than me looked into this?

I didn't realize this message was going to get so long. I'd better stop
now, as this is probably already enough to trigger an interminable
thread of discussion :-).
--
Tom.Horsley@mail.hcsc.com
Home: 511 Kingbird Circle Delray Beach FL 33444
Work: Harris Computers, 2101 W. Cypress Creek Rd. Ft. Lauderdale FL 33309
Support Project Vote Smart! They need your support in non-election years too!
(email pvs@neu.edu, 1-800-622-SMART, http://www.vote-smart.org)
Re: Interfacing with C structs, enums, etc. [ In reply to ]
Paul Marquess writes:
> There has been one alpha release of xsubpp with support for C
> structures - xsubpp-2.000a1. I can't remember if it made it to CPAN,
> but if you cannot find a copy drop me a line.
>
> That was quite a while ago and you will be glad to know that xsubpp is
> the next thing on my list once I finish off Source Filters (nearly
> done).
>

People, do not believe this guy! What he calls alpha looks like
production code for me! ;-)

I sent out a patch some time ago which skips over comments in struct
definitions and converts NULL-->undef (on read only).

Btw, I started to write C::Scan module with an intent to use it in
h2xs so that it will output STRUCT subsection automatically, and will
dump XSUBs for prototypes met. Unfortunately, it stalled after I spend
hours tracking perl bugs...

> For example I can parse this:
>
> struct S1 {
> int alpha ;
> short beta ;
> double gamma ;
> } ;
>
> struct S2 {
> int red ;
> struct S1 * blue ;
> short green ;
> double yellow ;
> } ;
>

and now you may leave C comments there as well.

Ilya
Re: Interfacing with C structs, enums, etc. [ In reply to ]
>> * I know it is probably impossible to make a mechanism that will work with
>> any existing C code without being at least as complex as a full blown C
>> compiler. Has anyone considered adding a "perl" target to gcc which could
>> compile arbitrary C or C++ code into a perl XS module that provides access
>> to all the data structures, enums, and functions?

>Sounds like a BIG job - would be nice though.

>The alpha release of xsubpp gets by quite nicely with pseudo-C
>structure definitions. Of course I have made no attempt to parse a
>proper C structure.

>For example I can parse this:

>struct S1 {
> int alpha ;
> short beta ;
> double gamma ;
> } ;
>
>struct S2 {
> int red ;
> struct S1 * blue ;
> short green ;
> double yellow ;
> } ;

But can you parse this? :-)/2 {you know, the way god and dennis intended :-}

struct S1 {
int alpha;
short beta;
double gamma;
};

struct S2 {
int red;
struct S1 * blue;
short green;
double yellow;
};

Has anyone ever thought about just taking the gcc C parsing code and using
that? After all, it's producing stabs on stab machines with the right
stuff. This seems a bit like reinventing the wheel. I started with this
method many many many years ago, before I think there was even a
comp.lang.perl newsgroup. It was so prone to failure I nearly cried.
What about typedefs? What about #defines for aliaseed structure fields?
This is a nightmare, and having the compiler do it for me was one of the
few brilliant things I've ever done. That's when c2ph was born. Are we
going to do as well as it can do? If not, I'm going to make it spit out
object code instaead and just use that. It has a much better success rate
than any parsing I've ever been able to do. Of course, it won't work if
you don't have a sun system and/or gcc with stab production. I don't see
why it should be hard to make gcc give stabs even for architecutres that
don't support it, and this seems ultimately a better alternative than
going through all the pain of parsing it all yourself?

--tom
Re: Interfacing with C structs, enums, etc. [ In reply to ]
From: tom@amber.ssd.hcsc.com (Tom Horsley)
>
> After many months of neglect, I may be able to get back to work on my Wcl to
> perl interface. One of the things I will need to do is provide some way for
> the perl code to access massive numbers of different callback info structs
> and massive numbers of the various widget convenience functions, etc. It
> would sure be nice to construct all these interfaces automagically.
>
> I know there has been some work on this, but I haven't really kept track of
> things too well, and I apologize in advance for asking questions I probably
> ought to know the answers to:
>
> * Where do I find the existing work that has already been done to interface
> with structs? Is it already part of 5.002beta1? Or can I ftp it from
> somewhere?

There has been one alpha release of xsubpp with support for C
structures - xsubpp-2.000a1. I can't remember if it made it to CPAN,
but if you cannot find a copy drop me a line.

That was quite a while ago and you will be glad to know that xsubpp is
the next thing on my list once I finish off Source Filters (nearly
done).


> * What is the preferred mechanism for providing perl code with access to
> structs? Do people use a pack/unpack type approach, or do you make the
> struct look like a hash? Or do you just provide get and put functions
> for each field? How do you approach nested structs? How about unions?

Currently I use a tied hash to interface to both structures and unions,
and a tied array for C arrays.

> * I know it is probably impossible to make a mechanism that will work with
> any existing C code without being at least as complex as a full blown C
> compiler. Has anyone considered adding a "perl" target to gcc which could
> compile arbitrary C or C++ code into a perl XS module that provides access
> to all the data structures, enums, and functions?

Sounds like a BIG job - would be nice though.

The alpha release of xsubpp gets by quite nicely with pseudo-C
structure definitions. Of course I have made no attempt to parse a
proper C structure.

For example I can parse this:

struct S1 {
int alpha ;
short beta ;
double gamma ;
} ;

struct S2 {
int red ;
struct S1 * blue ;
short green ;
double yellow ;
} ;


Paul
Re: Interfacing with C structs, enums, etc. [ In reply to ]
From: Ilya Zakharevich <ilya@math.ohio-state.edu>
>
...
> Btw, the solution which looks the best for me is to have an INCLUDE:
> directive in xsubpp, and spit STRUCTs and XSUBs generated from
> prototypes to separate files.

Tim has already requested INCLUDE: - it's on my todo list.

Paul
Re: Interfacing with C structs, enums, etc. [ In reply to ]
From: Dean Roehrich <roehrich@cray.com>
>
> > From: Ilya Zakharevich <ilya@math.ohio-state.edu>
> >
> > Paul Marquess writes:
> > > There has been one alpha release of xsubpp with support for C
> > > structures - xsubpp-2.000a1. I can't remember if it made it to CPAN,
> > > but if you cannot find a copy drop me a line.
> > >
> > > That was quite a while ago and you will be glad to know that xsubpp is
> > > the next thing on my list once I finish off Source Filters (nearly
> > > done).
> > >
> >
> > People, do not believe this guy! What he calls alpha looks like
> > production code for me! ;-)
> >
> > I sent out a patch some time ago which skips over comments in struct
> > definitions and converts NULL-->undef (on read only).

Don't wory, I haven't forgotten about the patch. I will get round to it
(eventually).


> > Btw, I started to write C::Scan module with an intent to use it in
> > h2xs so that it will output STRUCT subsection automatically, and will
> > dump XSUBs for prototypes met. Unfortunately, it stalled after I spend
> > hours tracking perl bugs...
>
> Does all of this stuff (xsubpp, C::Scan) rely on ties? I'd like to see
> things a little more streamlined; just supply getter/setter methods and let
> me call them.


xsubpp is hard-wired to generate ties. It is possible that I could
change xsubpp to either generate only methods or to generate both. This
is one of the reasons why I still class the code as alpha.

Paul