[GAAS - Sat Oct 11 16:09:12 2003]:
> > I'm only reporting this bug because HTML::Parser passed make test fine
> > with HTML::Parser 3.31 using Perl 5.004 (an impressive feat to keep
> > this
> > Perl supported for so long). Now with HTML::Parser 3.32, I get this:
> >
> > t/textarea...........ok
> > t/tokeparser.........Use of uninitialized value at
> > blib/lib/HTML/TokeParser.pm line 52.
> > Use of uninitialized value at blib/lib/HTML/TokeParser.pm line 52.
> > t/tokeparser.........FAILED test 8
> > Failed 1/8 tests, 87.50% okay
>
> I don't really understand this yet, but this patch makes the
> test pass on perl-5.004.
>
> Index: lib/HTML/TokeParser.pm
> ===================================================================
> RCS file: /cvsroot/libwww-perl/html-parser/lib/HTML/TokeParser.pm,v
> retrieving revision 2.26
> diff -u -p -r2.26 TokeParser.pm
> --- lib/HTML/TokeParser.pm 10 Oct 2003 10:45:46 -0000 2.26
> +++ lib/HTML/TokeParser.pm 11 Oct 2003 20:04:42 -0000
> @@ -64,7 +64,7 @@ sub get_text
> my $self = shift;
> my @text;
> while (my $token = $self->get_token) {
> - my $type = $token->[0];
> + my $type = "$token->[0]";
> if ($type eq "T") {
> my $text = $token->[1];
> decode_entities($text) unless $token->[2];
>
> Without this the assigment to $type have the side effect
> of making $token->[0] undef. Very strange.
I am seeing this exact error with perl version 5.005_02 built for
sun4-solaris. If you look at the token array, you'll see that in fact
the first 2 elements are undef when they should not be. For instance,
in the following case I believe token->[1] should be 'img' but is undef:
DB<5> x $token
0 ARRAY(0x34fd7c)
0 undef
1 undef
2 HASH(0x34fce0)
'alt' => 'Perl'
'src' => 'camel.gif'
3 ARRAY(0x3ddf44)
0 'src'
1 'alt'
4 '<img src="camel.gif" alt="Perl">'
It looks like the problem occurs when parsing the HTML and building the
token array.
This doesn't appear to be a problem in later releases of perl.
id2001[...]cablelabs.com
