On Mon, Jan 19, 2004 at 05:16:07PM +0000 Nick Ing-Simmons wrote:
> Tassilo Parseval <[EMAIL PROTECTED]> writes:
> >On Mon, Jan 19, 2004 at 09:15:54AM +0000 Nick Ing-Simmons wrote:
> >> DO NOT malloc() and put in PV slot.
> >
> >Hmmh, why not?
>
> Because it will segfault on Win32 and anywhere else where
> perl does not use system malloc() as its allocator.
> Perl assumes it owns SvPVX and will free it - to perl's allocator
> when it is no longer required. It also assumes
> that it can
>
> New(xxx,foo,char,SvCUR(sv)+1);
> memcpy(foo,SvPVX(sv),SvCUR(sv)+1);
>
>
>
> SvPVX(sv) = malloc(42);
> ...
>
> When SV's REFCNT==0 perl does:
> Perl_Free(SvPVX(sv))
>
> If Perl_Free != free this segfaults.
>
> Notice that on Win32 in particular perl does NOT use system malloc
> (or even anything remotely like it), and many platforms
> use perl's malloc for speed.
>
> >For me, PV has never really been for strings only. It's a
> >pointer value so storing pointers in it seems natural to me.
> I am not saying it has to be a string. I am saying it MUST
> be allocated with the allocator perl is using - malloc() is WRONG -
> It must be New() allocated.
With New, you mean the macro New(), I hope (as opposed to usemymalloc).
In this case I am relatively relieved since I adopted the habit of
always using New/Safefree. So I should be on the safe side (knocking on
wood).
Tassilo
--
$_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus})!JAPH!qq(rehtona{tsuJbus#;
$_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval
