Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling

Re: weird XS_unpack_charPtrPtr error

by tlm (Prior)
on Apr 06, 2009 at 23:27 UTC ( #755892=note: print w/replies, xml ) Need Help??

in reply to weird XS_unpack_charPtrPtr error

A belated update. Shortly after posting, I (re-)discovered the NOCLEAN option to Inline, which enabled me to examine the generated *.c file, and from this I could see where the references to XS_unpack_charPtrPtr. So I never got to use BrowserUk's useful trick. (I've added to the old bag o' tricks for the future. Thanks.)

I found that apparently Inline was getting thrown off by the fact that in my C code some times I had the word static in the declaration of a function, but not in its subsequent definition; e.g.

static void foo (); ... void foo () { ... }
or even
static void foo (); ... static void foo () { ... }
...with the static keyword on a separate line. Either way, Inline was incorrectly treating these functions as ones to make callable from Perl. So adding the static keyword to the function definitions where Inline wanted it took care of the XS_unpack_charPtrPtr error. (It is a mystery to me why this problem arose only when I tried to make a downloadable package, and not before during my tests, since the C source code was exactly the same in both cases.)

But as it happened, all this turned out to be for nothing, and syphilis's observations and suggestions were right on the money. What I had been trying to do did not produce the desired degree of independence from Inline. For what I needed InlineX::C2XS was indeed the right tool. Many thanks!

the lowliest monk

Replies are listed 'Best First'.
Re^2: weird XS_unpack_charPtrPtr error
by syphilis (Chancellor) on Apr 07, 2009 at 01:07 UTC
    I had the word static in the declaration of a function, but not in its subsequent definition

    With Inline::C, function declarations are usually unnecessary. I wouldn't go so far as to say that they're *never* needed, but I've not yet struck a situation where they're required.

    with the static keyword on a separate line

    It's a bug that having 'static' on a separate line is producing different behaviour. In fact, I think it's a bug in the Parse::RecDescent parsing of the code - if you parse with ParseRegExp the problem disappears. ParseRegExp is a much faster parser, too. You use it by specifying the Inline config option USING => 'ParseRegExp',
    (ParseRegExp is broken in Inline-0.44, but works fine for me in Inline-0.45.)

    I'm not sure if it's a bug or a feature that the static keyword makes the function invisible from perl, but that's certainly the way it is for me. I'm still a little bit puzzled that you needed to use static to get the desired effect. I've written plenty of Inline::C functions that are uncallable from Perl, and haven't had to do anything like that. Of course, if I call them from Perl, then I get a runtime error straight away - and they do have to be defined in the script *before* any of the other Inline::C functions that call them.

    Anyway, good that you got it working - and I much appreciate your feedback.


Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://755892]
[Discipulus]: the survey results are interesting: i'm highly underpaid!

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (5)
As of 2017-04-27 08:31 GMT
Find Nodes?
    Voting Booth?
    I'm a fool:

    Results (501 votes). Check out past polls.