Dan Sugalski wrote:
>
> At 08:57 PM 10/12/00 +0100, Simon Cozens wrote:
> >On Thu, Oct 12, 2000 at 03:43:07PM -0400, Dan Sugalski wrote:
> > > Doing this also means someone writing an app with an embedded perl
> > > interpreter can call into perl code the same way as they call into any C
> > > library.
> >
> >Of course, the problem comes that we can't have anonymous functions in C.
>
> Sure we do. You can get a pointer to a function, and then call that
> function through the pointer. (Though argument handling's rather dodgy)
>
> >That is, if we want to call Perl sub "foo", we'll really need to call
> >something like
> >
> > call_perl("foo", ..args... );
> >
> >whereas we'd much rather do this:
> >
> > foo(..args..)
> >
> >(Especially since C's handling of varargs is, well, unpleasant.)
cat <<ENDEND >> rfc334.h:
/* based on http://www.eskimo.com/~scs/C-faq/q15.4.html */
void *call_perl(char *PerlFuncName, ...);
ENDEND
Which then makes the RFC121 -oh output simple and easy: perl routines
which have been marked with a RFC334 attribute indicating their C calling
convention get two lines written to standard output (or the designated
header file):
one is a macro, which will call callperl directly with the name and the args,
#define fooDIRECT(A,B,C) callperl(foo, A,B,C)
and the other is a wrapper.
perlval *foo(int A, perlval *B, char *C);
....
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
"After jotting these points down, we felt better."
