Re^8: SvUV vs SvIV for pointers in SVs, typemap

[patcat88]

in reply to Re^7: SvUV vs SvIV for pointers in SVs, typemap
in thread SvUV vs SvIV for pointers in SVs, typemap

#!/usr/bin/perl -w
use Devel::Peek;
$ptrUV = unpack('J',pack('P[12]',"Hello World"));
$ptrIV = unpack('j',pack('P[12]',"Hello World"));
print Dump($ptrUV);
print Dump($ptrIV);
$ptrUV += 2**31;
print Dump($ptrUV);

SV = IV(0x182a260) at 0x182a264
  REFCNT = 1
  FLAGS = (IOK,pIOK)
  IV = 28545556
SV = IV(0x182a3e0) at 0x182a3e4
  REFCNT = 1
  FLAGS = (IOK,pIOK)
  IV = 26107564
SV = IV(0x182a260) at 0x182a264
  REFCNT = 1
  FLAGS = (IOK,pIOK,IsUV)
  UV = 2176029204

Perl keeps all unsigneds as IVs until they are greater than IV_MAX (~ +2 billion), then it uses the UV flag/UV mode. [sv.c#l1620 in perl.git] But, if the pointer is larger than 2 billion, and the user manipulates the pointer, for struct offsets for example, before passing it to unpack, or passes the scalar with the pointer inside it to an XSUB that takes a pointer (bad XSUB design right?)

[BrowserUk]

There is also the possibility of performing pointer arithmetic with two pointers, one just before the 2GB boundary and one just after it. Thus mixing IV and UV math.

Whether deriving offsets in structs, or extracting or manipulating sub-strings, I'm not at all convinced that there are not places within the Perl sources themselves where such manipulations are done, that work only because most 32-bit Perls run limited to 2GB.

Certainly, when I was playing with 32-bit perl made /largeaddressaware and with /3GB set, I saw enough weirdness and crashes to give up on the idea of using that instead of a 64-bit Perl in order to get access to my full complement of ram.

[ikegami]

If someone changes your internals to the point of failure, it doesn't make your design bad.

Besides, if you were to fake the internals using pack and ended up with a UV, it would still work with the existing typemap.