patcat88 has asked for the wisdom of the Perl Monks concerning the following question:
I am trying to avoid copying the buffer redundantly by doing a sv_setpvn every time. Is this the correct way to have a function write directly into the string pointer in the SV? I did look at the source code for sv_setpvn to write this, but I'm not sure if this is the correct way to do it or not, especially with the null character on the end of the buffer beyond the end of the CUR length. Is buffer ST(1) also? My rough testing says this code works, but are there any edge cases where it wouldn't (magic, undef, SVIV instead of SVPV, reference SV, etc)?
I did find out that even though Perl_sv_grow can handle an undef SV/non PV SV and will upgrade it for you, the macro SvGROW (((XPV*) (mySvPtr)->sv_any)->xpv_len < (length) ? Perl_sv_grow(my_perl,mySvPtr,length) : ((mySvPtr)->sv_u.svu_pv)) on Perl 5.10.0 can't handle a SV without a PV part (access violation, null pointer dereference), so I had to add the SvUPGRADE manually, even though its sorta redundant. Hypothetically I thought of replacing the SvGROW with the function call version, or is that forbidden in XS since the functions behind macros aren't frozen in perl? Also I see a performance reduction if the macro is replaced with the function.
Also in the source code for sv_setpvn I saw "SV_CHECK_THINKFIRST_COW_DROP(sv);" ? Do I need it? What is it? This is a made up Win32 function, but its irrelavent. I'm more interested in bugs in my code with the SV interaction.
I did find out that even though Perl_sv_grow can handle an undef SV/non PV SV and will upgrade it for you, the macro SvGROW (((XPV*) (mySvPtr)->sv_any)->xpv_len < (length) ? Perl_sv_grow(my_perl,mySvPtr,length) : ((mySvPtr)->sv_u.svu_pv)) on Perl 5.10.0 can't handle a SV without a PV part (access violation, null pointer dereference), so I had to add the SvUPGRADE manually, even though its sorta redundant. Hypothetically I thought of replacing the SvGROW with the function call version, or is that forbidden in XS since the functions behind macros aren't frozen in perl? Also I see a performance reduction if the macro is replaced with the function.
int ReadStream(handle, buffer, bufferSize, bytesRead) unsigned long handle char * buffer = NO_INIT unsigned long bufferSize unsigned long bytesRead = NO_INIT CODE: SvUPGRADE((SV*)ST(1), SVt_PV); buffer = SvGROW((SV*)ST(1), bufferSize+1); RETVAL = ReadStream(handle, buffer, bufferSize, &bytesRead); buffer[bytesRead] = '\0'; SvCUR_set((SV*)ST(1), bytesRead); (void)SvPOK_only_UTF8((SV*)ST(1)); SvTAINT(ST(1)); SvSETMAGIC(ST(1)); OUTPUT: RETVAL bytesRead
Also in the source code for sv_setpvn I saw "SV_CHECK_THINKFIRST_COW_DROP(sv);" ? Do I need it? What is it? This is a made up Win32 function, but its irrelavent. I'm more interested in bugs in my code with the SV interaction.
|
---|
Replies are listed 'Best First'. | |
---|---|
Re: XS, function writing directly into SV PV pointer, SvGROW doesn't like non PV SVs
by ikegami (Patriarch) on Oct 29, 2010 at 07:09 UTC |
Back to
Seekers of Perl Wisdom