Norbert Gruener wrote:
> Hello Brian,
>
> first of all I wish you a Happy New Year !!! :-)))
>
> On Fri, Dec 15 2000, Brian Ingerson wrote:
>
>> I'm interested in knowing how your XS to Inline conversion goes. Your
>> feedback could help me improve future versions.
>
>
> Over the holidays I made my first tests how to convert my AFSperl
> XS-module to Inline. And I run into some problems.
>
> o In the C-Cookbook you state that "a variable length argument list"
> must contain at least one element. But with the XS interface it is
> possible to specify an empty list. Well, for the moment I have a
> workaround but I just wonder if this restriction will stay for ever ?
To indicate a variable list in C you say something like:
int foo(long bar, ...) {
But (on my compiler at least) this is invalid:
int foo(...) {
And since the XS I generate does the parameter checking, I can't do this
and actually pass in values:
int foo() {
The other problem is that I generate special C code when I see '...', to
keep the stack pointers correct.
So what should I do? I guess the best way to fix this would be to always
allow stack handling in any function (generate the special code) and
turn off the XS parameter check (which I don't know how to do yet. do
you?) and allow this syntax to mean 'any number of parameters':
int foo() {
Any other ideas?
>
> o If I make use of the possibility to have multiple Inline C sections I
> get a problem. In order to demonstrate it, I have prepared a very
> simple test case. In the first section I specify a C function and in
> the second section I specify a second C function which is calling the
> first function. I also call that first C function from the Perl
> code. The call from the Perl code is working. Then I call the
> second C function from the Perl code which is finally calling the
> first C function. As soon as the first C function is called from the
> second C function I get an error that this function is "an undefined
> symbol". The reason is that each C section is stored in a separate
> object library.
I found this out a long time ago. I call it a 'feature' ;-)
(It allows you keep your functions seperated from each other.)
I'd be interested in knowing why you want to do this. Your functions are
all available from Perl. Why do they need to access each other? And if
they do, why can't they all be in one C section instead of two or more?
I'm not doubting you, I just want the rationale. That way I can make
better design decisions.
I think this is a Dynaloader issue. You need to set certain Dynaloader
options to allow functions in separate modules to see each other.
(hopefully portably) If you can find out what these Dynaloader flags
are, I'll add them to the configuration options. (Try doing a simple
example in XS with 2 different modules)
Brian
