Update: Found this:

/* Size_t:
 *    This symbol holds the type used to declare length parameters
 *    for string functions.  It is usually size_t, but may be
 *    unsigned long, int, etc.  It may be necessary to include
 *    <sys/types.h> to get any typedef'ed information.
 */
#define Size_t size_t     /* length paramater for string functions */

#define MEM_SIZE Size_t

typedef MEM_SIZE STRLEN;

    STRLEN      xpv_cur;        /* length of svu_pv as a C string */
    STRLEN      xpv_len         /* allocated size */
[download]

I have no idea what that means, but it appears to be configurable somehow since Size_t is defined in a file called "uconfig.h".

scalars don't have a length. Do you mean the string contained within a scalar?

That's why I said "PV" in the title.

However, I recently heard many builtins (index? substr?) use 32-bit indexes.

That would (almost) explain what I'm seeing. I'm returning an SV with the PV set to point at an 8GB lump of memory mapped file. I'm setting CUR and LEN myself, and length duly reflects the numbers I set. But if I try to substr that scalar with an offset > 2**31, it bellyaches about "substr outside of string". Which perhaps suggests that they are doing some signed 32-bit math with what should be unsigned 64-bit values.

I guess I'll have to map the file as N x 2GB lumps so that they'll play nice with substr et al.

Looks like there are still some edges to be knocked off the 64-bit ports.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

RIP PCW It is as I've been saying!(Audio until 20090817)

But if I try to substr that scalar with an offset > 2**31, it bellyaches about "substr outside of string"

Heh ... on the x64 build of ActivePerl (perl-5.10.1, build 1006):

C:\>perl -we "print substr 'hello', (2 ** 32)+$_, 1 for 0..4"
hello
[download]

Cheers,
Rob

In bleed, I see I32 in pp_substr:

I32 pos;
I32 rem;
I32 fail;
[download]

It doesn't take much imagination to figure out how those vars are surely used. Right off the bat, one of the args is placed in pos:

pos = POPi;
[download]

How many bytes can be assigned to a $var is a different thing. As ikegami points out. But then again we get to the practical matter of how many chars(bytes) make sense to assign to a single Perl variable? I would argue that once this gets past a couple of billion (or even just a 100 million), the algorithm is suspect.

Suffice to say, this has nothing to do with the length of variable names; and there is nothing "suspect" about using memory-mapped virtual address space.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

RIP PCW It is as I've been saying!(Audio until 20090817)

Ok missed your point about length of variable names. I didn't get that from original question (just went past PV).

This appears to have a LOT to do about memory-mapped virtual address space. If you create a structure that cannot fit into memory at once, the performance penalty can be awesome depending upon how localized the access is to this structure.