On Wed, Jan 29, 2003 at 02:25:50PM +0000, Miah Gregory wrote:
> /* check to see if the requested offset is out of range */
> if (offset > datalength)
> {
You don't need to do this savepv or savepv here.
> /* copy the original string, and set the second half to be empty*/
> aptr = savepvn(dataptr, datalength);
> bptr = savepv("");
> aptrlength = datalength;
> bptrlength = 0;
> }
> else
> {
> /* copy and split the string */
> aptr = savepvn(dataptr, offset);
> bptr = savepvn(dataptr + offset, datalength - offset);
> aptrlength = offset;
> bptrlength = datalength - offset;
> }
These two will *copy* the data from aptr and bpr to the two variables,
not "steal" the pointers. As the savepv/savepvn have just made malloc()ed
copies, and setpvn() doesn't take the pointer from you, so each time round
you've got 2 more malloc()ed bits of data that aren't free()d.
replace the if clause with
if (offset > datalength)
{
/* copy the original string, and set the second half to be empty*/
aptr = dataptr);
bptr = "";
aptrlength = datalength;
bptrlength = 0;
}
else
{
/* copy and split the string */
aptr = dataptr;
bptr = dataptr + offset;
aptrlength = offset;
bptrlength = datalength - offset;
}
and I believe that it will all work as before, but no leaks.
> Sort of unrelated, I notice that there are a lot of functions with names
> like xxx_mg, whose descriptions talk about handling 'set' magic. What does
> this mean?
I'd suggest reading perlguts, which describes itself as "Introduction to the
Perl API" for more general information.
I don't know if it's covered there coherently, but you'd need to worry about
set magic if you were setting the values on SVs passed in to you. The new
SVs you've just created don't have any magic, so you aren't going wrong by
"not handling 'set' magic"
"magic" implements all sorts of special behaviour by allowing SVs to have
routines attached that are called when their value is got, set, cleared,
etc. "not handling magic" means that a routine doesn't look to see if there
is any "magic" attached, and therefore doesn't do the correct thing -
calling any magic routines, as a consequence of not even looking.
> PS. I'm subscribed to the list, so you don't need to CC me. :-)
It tends to be the custom. It's also the default on all the Unix mailers
that I can remember to either reply only to the sender, or to "everybody"
(ie the sender plus the list). There are long flame wars to be had about
whether lists should set a reply-to back to the list. Let's not go there :-)
Nicholas Clark
