Re: PL/Perl Does not Like vstrings

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "David E(dot) Wheeler" <david(at)justatheory(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PL/Perl Does not Like vstrings
Date: 2012-01-04 20:13:28
Message-ID: 4F04B2E8.1050808@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 01/04/2012 12:56 PM, Tom Lane wrote:
> Andrew Dunstan<andrew(at)dunslane(dot)net> writes:
>> The docs (perldoc perlvar) seem to suggest $^V isn't an SV (i.e. a
>> scalar) but some other sort of animal:
> Yeah, it's a version object, but I'd have thought that SvPV and friends
> would automatically stringify such an object. Otherwise, practically
> any kind of perl extension could be crashed by passing it one, no?
>
>> But Util.xs::util_elog() expects an SV and doesn't check whether or not
>> it actually has one. I've found a few other ways of crashing this call
>> (e.g. by passing a typeglob), so maybe we need to test that we actually
>> have an SV. I think SvOK() is what we'd use for that - perl gurus please
>> confirm.
> I looked at that last night but it appeared that SvOK would be perfectly
> happy. (Didn't actually try it, though, I was just eyeballing the flags
> in gdb.)
>
>

I tested it and you're right, it doesn't help. I don't see what else we
can do about it. There doesn't appear to be any test for an SV in the API.

cheers

andrew

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2012-01-04 20:24:27 Avoid FK validations for no-rewrite ALTER TABLE ALTER TYPE
Previous Message Robert Haas 2012-01-04 20:04:48 Re: 16-bit page checksums for 9.2