A typical way of dealing with such things, is to create the buffer in the high level language, in this case Perl (but it's been done in like this in VB, too), and pass the pointer to it to C, which can fill it up. That way, there's no alloc() related madness waiting on your C code. All you have to do is prefill a scalar with a large enough string.

At the worst, you can still copy the contents of the buffer over to the Perl scalar just before you finish. In VB it was customary to use an API call for that: hMemCpy() in Windows 3.1, and RtlMoveMemory for Win32 — the only kind of Windows that's still alive. But of course, the strings were never that long, so maybe that approach isn't so practical.

As an aside, there are several pointer related templates available for pack/unpack, such as "P"/"p".

Hmm. I'm not sure why that might be a problem. There's a HAS_64K_LIMIT defined in dosish.h, but it seems unlikely to be related. Try this as an alternative and see what happens.

htm_sv = newSV(filesize + 1);
SvPOK_on(htm_sv);
SvCUR_set(filesize);
ptr = SvPVX(htm_sv);
Copy(*htmFile, ptr, filesize, char);
XPUSHs(sv_2mortal(htm_sv));
[download]

(newSVpvn takes two arguments -- a char* and a STRLEN -- while I only see one in your example... but I assume that's just a typo, as it would have been a compile-time error and there's no equivalent that uses only one arg.)

use warnings;
use strict;

use Inline C => Config =>
    BUILD_NOISY => 1;

use Inline C => <<'EOC';

void foo(char * htmFile, int len) {
     dXSARGS;
     sp = mark;
     XPUSHs(sv_2mortal(newSVpv(htmFile, len)));
     PUTBACK;
     XSRETURN(1);
}

EOC

my $len = 8000000;
my $z = 'z' x $len;

my $copy = foo($z, $len);

print length($copy), "\n";
[download]

I need to finish it one of these days.