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

Reply via email to