I recently tracked down a difficult bug that occured only when one of my
XS modules was used in conjunction with certain other XS modules (e.g.,
XML::Parser or String::Approx). It turned out to be due to the
incorrect assumption that PL_na will always be zero. Specifically, we used
newSVpv
On 25.09.2013 20:56, Jan Dubois wrote:
On Wed, Sep 25, 2013 at 11:50 AM, Torsten Schoenfeld
kaffeeti...@gmx.de wrote:
newSVpv (string, PL_na) // do not do this
Is this recomended anywhere?
Probably not. But http://grep.cpan.me/?q=newSVpv.*PL_na does show
quite a few hits, only roughly
On 12.10.2011 12:38, Jeffrey Ratcliffe wrote:
Assuming we have
Foo.xs
Fo.pm
Foo_Bar.xs
how do I get Foo::Bar to load/boot/import at the same time as Foo on use Foo?
You have to call Foo_Bar.xs' BOOT section (which wires up the xsubs)
from Foo.xs' BOOT section. Look at Glib.xs' BOOT section
On 12.10.2011 15:24, Jeffrey Ratcliffe wrote:
On 12 October 2011 13:11, Torsten Schoenfeldkaffeeti...@gmx.de wrote:
You have to call Foo_Bar.xs' BOOT section (which wires up the xsubs) from
Foo.xs' BOOT section. Look at Glib.xs' BOOT section for an example. For
Gtk2 and below, this is
On 19.07.2010 12:52, ravips wrote:
1. Should a CLEANUP tag be added which cleans up the array
( av_clear; av_undef;)?
No, you return the AV to the caller who then assumes ownership, so you
mustn't free it. I think you should even be able to get rid of the
sv_2mortal call since the AV*
On 07.06.2010 10:43, Florian Weimer wrote:
Is the following the correct code sequence to return an array
reference or nothing (if result is 0) from an XS function?
PPCODE:
AV *result = 0;
if (some_condition) {
result = newAV();
Jeffrey Ratcliffe wrote:
I attach the ExtUtils::Constant example from the blog.
Try changing, in Test.pm, this:
sub test {
print XST_ENUM_1, \n;
}
to this:
sub test {
print XST_ENUM_1(), \n;
}
-Torsten
On Mon, 2007-09-10 at 11:15 +0200, Scott Lanning wrote:
I think it's a bug (or lack of C++ functionality) in xsubpp,
but I'm not ruling out a self-introduced problem. :)
Yep, xsubpp's OVERLOAD support is broken.
Here's what's lacking:
XS(XS_Ogre__Animation_nil); /* prototype to pass
On Fri, 2007-10-26 at 23:33 +1000, Sisyphus wrote:
During compilation I get the errors:
_64bit_pl_498e.xs:20: error: syntax error before SvGUInt64
_64bit_pl_498e.xs:30: error: syntax error before value
_64bit_pl_498e.xs: In function `newSVGUInt64':
_64bit_pl_498e.xs:40: error: `value'
On Wed, 2007-10-24 at 21:49 +0100, William S Fulton wrote:
Any portable solutions for extracting the unsigned long long number?
The best effort I can provide is what's in Glib. They do what Sisyphus
suggests: represent big numbers as strings if necessary.
#ifdef _MSC_VER
# include stdlib.h
On Wed, 2006-10-04 at 17:15 -0400, Lobsingerp,Peter [CIS] wrote:
I have tinkered with it and the code bellow works properly, although
it should be equivalent to the above code. The only modification is
holding the result of av_shift(Timeseries) in an intermediate pointer.
SvNV is a macro.
On Wed, 2005-05-25 at 11:38 +1000, Sisyphus wrote:
is there any way to reliably convert long longs (64bit integers) to SVs
(and back) on 32bit platforms without losing information, and without
compiling with -Duse64bitint? Both, IV and NV don't seem to provide
enough room to store large
Aloha,
is there any way to reliably convert long longs (64bit integers) to SVs
(and back) on 32bit platforms without losing information, and without
compiling with -Duse64bitint? Both, IV and NV don't seem to provide
enough room to store large values.
--
Thanks for any pointers,
-Torsten
13 matches
Mail list logo