Re: Core dump running PL/Perl installcheck with bleadperl [PATCH]

From: Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Core dump running PL/Perl installcheck with bleadperl [PATCH]
Date: 2010-03-08 09:36:32
Message-ID: 20100308093632.GV1375@timac.local
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Mar 07, 2010 at 12:11:26PM -0500, Tom Lane wrote:
> Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com> writes:
> > I encountered a core dump running PL/Perl installcheck with a very
> > recent git HEAD of PostgreSQL and a not quite so recent git HEAD of perl.
>
> > The cause is a subtle difference between SvTYPE(sv) == SVt_RV and
> > SvROK(sv). The former is checking a low-level implementation detail
> > while the later is directly checking "does this sv contains a reference".
>
> Hmm. Seems like this patch begs the question: if checking SvTYPE(*svp)
> isn't safe, why is it safe to look at SvTYPE(SvRV(*svp))? Shouldn't the
> tests against SVt_PVHV be made more abstract as well?

Some SvTYPE values, like SVt_RV, allow the SV to hold one of a number of
different kinds of things. Others, like SVt_PVHV, don't.

No, I don't like it either but that's the way the "Jenga tower made of
yaks" (to use a phrase recently coined by one of the perl maintainers)
has grown. Something like an SvRVHVOK(sv) would be welcome sugar.

Tim.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Marko Tiikkaja 2010-03-08 09:38:47 Re: SQL compatibility reminder: MySQL vs PostgreSQL
Previous Message Pierre C 2010-03-08 09:17:55 Re: SQL compatibility reminder: MySQL vs PostgreSQL