develooper Front page | perl.perl5.porters | Postings from April 2012

[perl #23953] Bug in lib/Net/Domain.pm

From:
Father Chrysostomos via RT
Date:
April 28, 2012 14:23
Subject:
[perl #23953] Bug in lib/Net/Domain.pm
Message ID:
rt-3.6.HEAD-4610-1335648217-351.23953-15-0@perl.org
On Sat Apr 28 03:16:11 2012, Hugmeir wrote:
> On Mon Sep 22 11:39:01 2003, rjk-perl-p5p@tamias.net wrote:
> > On Mon, Sep 22, 2003 at 11:57:53AM -0000, frankj@osc.no (via RT)
> > wrote:
> > 
> > > diff -cr perl-5.8.1-RC4/lib/Net/Domain.pm perl-5.8.1-RC4-
> > fix/lib/Net/Domain.pm
> > > *** perl-5.8.1-RC4/lib/Net/Domain.pm    Thu Jul 10 08:11:51 2003
> > > --- perl-5.8.1-RC4-fix/lib/Net/Domain.pm        Mon Sep 22 13:44:20
> > 2003
> > > ***************
> > > *** 176,181 ****
> > > --- 176,182 ----
> > >             my @h = ();
> > >             while(length($dom)) {
> > >                 push(@h, "$host.$dom");
> > > +               $dom =~ s/^\.//g;
> > >                 $dom =~ s/^[^.]+.//;
> > >             }
> > >             unshift(@hosts,@h);
> > > ===================================================================
> > > As you can see from the original code above, if $dom contains an
> > extranous
> > > ".", the loop will never finish.  It will also gobble up all memory
> > due
> > > to the push command.
> > 
> > I believe that code will also enter an infinite loop if $dom ends up
> > being
> > one character long.  (Presumably this shouldn't happen with well-
> > formed
> > domains, but the potential for an infinite loop should still be
> > corrected.)
> > 
> > The easiest fix is to change the second substitution:
> > 
> > $dom =~ s/^[^.]+.?//;
> > 
> > A better fix might be to test specifically for $dom being one
> > character
> > long and returning some sort of error.  I'd say that's for someone who
> > knows more about the module than I to determine.
> > 
> > Ronald
> > 
> 
> 
> Looks like this was already applied to Net::Domain. This ticket was
> closed for a while in 2008, then reopened by stmpeters. I'm guessing
> that was a mistake? Or is there any reason why this shouldn't be marked
> as resolved again?

I know I’m not answering your question, but this is in the cpan/
directory in blead.  Porting/Maintainers.pl lists upstream as undef, but
I know that Graham Barr’s repository (I don’t remember where that is)
has patches applied that are not in the CPAN release, making CPAN
effectively upstream, I suppose.

-- 

Father Chrysostomos


---
via perlbug:  queue: perl5 status: open
https://rt.perl.org:443/rt3/Ticket/Display.html?id=23953



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