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
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
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, 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 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 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
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 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();
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 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
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
13 matches
Mail list logo
