Skip Menu |

This queue is for tickets about the Net-DNS CPAN distribution.

Report information
The Basics
Id: 112363
Status: rejected
Priority: 0/
Queue: Net-DNS

People
Owner: Nobody in particular
Requestors: Mark.Martinec [...] ijs.si
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: 1.04
Fixed in: (no value)



Subject: POSIX syntax [. .] belongs inside character classes
This is actually a bug in perl 5.23.8, but affects Net::DNS and can be easily avoided. The bug is described in: [perl #127604] https://rt.perl.org/Ticket/Display.html?id=127604 false positive: POSIX syntax [. .] belongs inside character classes in regex This is how it affects Net::DNS::Resolver - the following warnings are issued: POSIX syntax [. .] belongs inside character classes (but this one isn't implemented) in regex; marked by <-- HERE in m/[.].*[.] <-- HERE / at .../perl-5.23.8/lib/site_perl/5.23.8/Net/DNS/Resolver/Base.pm line 1063. POSIX syntax [. .] belongs inside character classes (but this one isn't implemented) in regex; marked by <-- HERE in m/[.].*[.] <-- HERE / at .../perl-5.23.8/lib/site_perl/5.23.8/Net/DNS/Resolver/Base.pm line 1130. I suggest avoiding unnecessary use of a character class and use a simpler regexp, e.g.: --- Net/DNS/Resolver/Base.pm~ 2015-12-08 20:46:21.000000000 +0100 +++ Net/DNS/Resolver/Base.pm 2016-02-24 15:53:15.849787311 +0100 @@ -1061,5 +1061,5 @@ unless USE_SOCKET_IP; } else { - my $localaddr = $srcaddr =~ /[.].*[.]/ ? $srcaddr : '0.0.0.0'; + my $localaddr = $srcaddr =~ /\. .* \./x ? $srcaddr : '0.0.0.0'; $sock = IO::Socket::IP->new( @@ -1128,5 +1128,5 @@ return $sock if $sock = $self->{persistent}{$sock_key}; - my $localaddr = $srcaddr =~ /[.].*[.]/ ? $srcaddr : '0.0.0.0'; + my $localaddr = $srcaddr =~ /\. .* \./x ? $srcaddr : '0.0.0.0'; $sock = IO::Socket::IP->new(
From: rwfranks [...] acm.org
On Wed Feb 24 10:06:08 2016, Mark.Martinec@ijs.si wrote: Show quoted text
> This is actually a bug in perl 5.23.8, but affects Net::DNS
which doubtless will be resolved by a compiler guru Show quoted text
> and can be easily avoided.
and already has been, for entirely unconnected reasons Thanks for the interesting observation, but no action needed.