Thanks for your prompt reply. I have a follow-up question, if you
don't mind.
On Jul 5, 2005, at 2:06 PM, Nicholas Clark wrote:
I suspect what has happened is that perl has re-used the same
scalar that
used to have magic. Because perl never (strictly nearly never)
downgrades
scalars, as soon as a particular scalar gets promoted as far as
PVMG, then
any other value assigned into it will leave it at PVMG. And if you
copy
that scalar above into another, the destination will be promoted to
PVMG,
even though it doesn't actually need to be. This is because the
copy code
promotes the destination based on the source scalar's type, before
it looks
into the source scalar to see how much data it's actually carrying.
So what I have going on is that I have data I'm passing in and out of
another language (PHP, specifically), and I'm holding it in either
opaque types (if it's an object or has discernible magic), or
converting into a native type. What I have here is that I have some
Perl data that's being passed into PHP, which then internally calls
back up to Perl to use it. This data certainly looks like normal
character data, but it's marked PVMG. Using an opaque type for this
data is more inconvenient than it might sound, since PHP's auto-
casting functions (cast me to a string/cast me to an int, etc.)
aren't terribly rich. Besides handling utf-8 data (which I both
think is probably the case here, as well as a general lost-cause
until php 5.2), do you see any inherent risks in downcasting this SVs
when making them available in PHP?
Basically I have:
($perlscalar) = $dbi->fetch();
# perlscalar is now magical, probably utf-8, but basically just a
char * of some sort
$php->someFunction($perlscalar);
and then in PHP
function someFunction($sv) {
// I'd like $sv to be a string here, as opposed to a scalar I need
to cast as a string
}
This seems to work fine with the downcasting operation (at least it
works as well as I would expect it to).
Do you see any other common situations that implementing this might
break? Specifically I'm worried about
having some data come in that looks very much like this, but who
really needs to be maintained as an opaque PVMG inside PHP.
Best,
George