Front page | perl.perl5.porters |
Postings from April 2007
On 4/10/07, Jan Dubois <jand@activestate.com> wrote:
> That is not really a limitation, as Perl arrays are limited in the same
> way (e.g. av_fetch() uses an I32 as the index, and negative values index
> from the end).
>
> I once tried to change Perl APIs to make everything 64-bit clean,
> but gave up because I eventually end up replacing every I32 with
> an IV, except for the few that just carry flags. For example
> even the magic structure has an I32 mg_len, which would need to
> become an IV for tied hashes etc.
Actually, the limitation of array indices doesn't apply in the case of
capture variables since the name of the variable is passed as a char*
to Perl_mg_get:
(gdb) run -e '"a" =~ /(.)/; say ${ "5" x 555 }'
Starting program: /var/src/perl5.git/perl -e '"a" =~ /(.)/; say ${ "5" x 555 }'
Breakpoint 1, Perl_reg_numbered_buff_fetch (rx=0x82d8388,
paren=2147483647, usesv=0x82c4338) at regcomp.c:4760
(gdb) frame 1
#1 0x080c610e in Perl_magic_get (sv=0x82c4338, mg=0x82d2e38) at mg.c:863
(gdb) p mg->mg_ptr
$6 = 0x82d7950 '5' <repeats 200 times>...
The atoi() on that mg_ptr in Perl_magic_get which then gets passed as
a I32 to Perl_reg_numbered_buff_fetch is the limitation currently:
(gdb) p mg->mg_ptr
$8 = 0x82d7950 '5' <repeats 200 times>...
(gdb) p atoi(mg->mg_ptr)
$9 = 2147483647
But of course then you'd have to store the offset as a string if you
wanted to access it pragmatically, which would be lame. Aside from the
obvious insanity of devising an algorithm that allocates so many
capture variables in the first place.
But indice pedantry aside I've become convinced that changing the
numbering from I32 isn't worth the effort and introduces discrepancy
between array indices and the range of capture variables.
Thread Previous
|
Thread Next