develooper Front page | perl.perl5.porters | Postings from July 2003

Act 2: Storing &PL_sv_undef as an array value

Thread Next
From:
Marcus Holland-Moritz
Date:
July 29, 2003 11:56
Subject:
Act 2: Storing &PL_sv_undef as an array value
Message ID:
006901c35603$21dedc50$0c2f1fac@R2D2
A couple of weeks ago, I thought I knew XS pretty well...

I just realized that AVs suffer from nearly the same
C<&PL_sv_undef> problem as HVs did.

C<&PL_sv_undef> is used to mark an array value as "not
initialized yet". Thus

  AV *a = newAV();
  av_push( a, &PL_sv_undef );

is _not_ equivalent to

  my @a;
  push @a, undef;

in the sense that for the XS code C<exists($a[0])> is
false while for the Perl code it is true. The "correct"
way to do it in XS would be:

  AV *a = newAV();
  av_push( a, newSV(0) );

So in fact, this is the equivalent of the placeholder
issue for arrays. (With the difference that it's probably
not as important because exists isn't used excessively on
arrays...)

My question is: now that we have a C<PL_sv_placeholder>,
should it also be used for uninitialized array values?

I noticed this behaviour while I was actually working on
a patch for perlguts.pod explaining why using C<&PL_sv_undef>
(and also C<&PL_sv_true> and C<&PL_sv_false>) as AV / HV
values can be dangerous and when it should be avoided.

While I'm at it, I could of course document this behaviour.
But somehow it now doesn't seem to be consistent with the
hash implementation...

I guess there are three options:

1) use C<PL_sv_placeholder> also for uninitialized array
   members (not sure if it's easily possible, but I'll
   have a look)

2) keep the behaviour as it is and document it

3) retract the C<PL_sv_placeholder> changes (for consistency)
   and document the old behaviour

Personally, I'd like to see (1), and I can't decide which
of (2) or (3) is worse.

-- Marcus


Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About