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?

sv_grow is part of the public API. You may use it.

SvGROW expects a scalar with a PV, whereas sv_grow takes any scalar and creates the PV if necessary. The later is more useful here, so I'm going to assume you switch to sv_grow from here on.

Is buffer ST(1) also?

I'm not sure of all the implications of the way you are doing — It doesn't seem right to access the Perl stack when you tell Perl how to handle arguments — so I'm just gonna point out the clean and simple way of doing it: take a scalar for parameter instead of a char*. You don't need any kind of implicit conversion if you already do everything explicitly. 

ReadStream(handle, buffer, bufferSize, bytesRead)
     unsigned long handle
     SV* sv_buffer
     unsigned long bufferSize
     unsigned long bytesRead = NO_INIT
PREINIT:
     char* buffer;
CODE:
     buffer = sv_grow(sv_buffer, bufferSize+1);
     ...
OUTPUT:   
     RETVAL
     bytesRead

[download]

but are there any edge cases where it wouldn't (magic, undef, SVIV instead of SVPV, reference SV, etc)?

You handle set magic. If you wanted to improve your function by having it append to any existing value, you'd have to process get magic to grab the value to which to append.

I don't know what happens if someone passes a read-only scalar for the buffer. This would include the undef (ReadStream(..., undef, ...)).

As for undefined scalars in general (ReadSream(..., my $buf, ...)), there's nothing special about those. They're just scalars with their OK flags off.

You handle any existing SV type since sv_grow upgrades.

You handle any existing values since sv_grow clears references and you clear anything simpler using SvPOK.

Also in the source code for sv_setpvn I saw "SV_CHECK_THINKFIRST_COW_DROP(sv);" ? Do I need it? What is it?

From the comment, sounds like an optimisation for a situation that shouldn't apply to you.

By the way, make sure that ReadStream doesn't expect bytesRead to be initialised.

In reply to Re: XS, function writing directly into SV PV pointer, SvGROW doesn't like non PV SVs by ikegami
in thread XS, function writing directly into SV PV pointer, SvGROW doesn't like non PV SVs by patcat88

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.