rsteinke has asked for the wisdom of the Perl Monks concerning the following question:

Is there some reason that the perl api function sv_mortalcopy() takes an SV* instead of a const SV*? Does it twiddle something inside the source SV, like SvIV() does to force a conversion? Similarly, why do the functions

newSVsv()
call_sv()

take SV* instead of const SV*?

Replies are listed 'Best First'.
Re: Why is sv_mortalcopy() non-const?
by Elian (Parson) on Jun 04, 2002 at 16:39 UTC
    const-ness is a hit or miss thing in the perl 5 source. It's generally added if someone thinks about it, but that doesn't happen all that often because we just don't think about it much.

    Also, since const-ness tends to propagate downward, you have to be careful adding it in after the fact, otherwise compilers will spew scads of warnings about passing in a const pointer to a routine that expects a normal one. Fixing the warnings generally requires source changes to extensions, and it's a little late to be doing that.

      Source changes to extensions shouldn't be an issue. You'd need to change functions that sv_mortalcopy() calls, but not functions that call sv_mortalcopy(), since conversion from SV* to const SV* is always fine.
        It's not that easy. You change sv_mortalcopy (or other functions or macros) to take a const pointer, and you get a const pointer inside them. That means any place you pass it into needs to be changed to const, and pretty soon you ripple through a good chunk of the source. That's definitely got repercussions. (It doesn't help that perl's horribly incestuous with itself--there's a goodly number of routines that fiddle with bits that you wouldn't expect, which make const-ing them impossible)