Bug #79915 for NetAddr-MAC: _mac_to_integers: local $_ doesn't play nice with map { hex }

Fri Sep 28 13:15:07 2012 BBYRD [...] cpan.org - Ticket created

Subject:

_mac_to_integers: local $_ doesn't play nice with map { hex }

Under certain conditions, "no symbol" MAC parsing fails because of an interaction between "local $_" and "map { hex }" statements. In this case, I was creating a NetAddr::MAC object within a BUILDARGs method, and every single time, it would fail to parse these kinds of strings. After some debugging, I found this: use Data::Dump 'pp'; use Devel::SimpleTrace; die pp(\@parts, [ map { hex } @parts ]); # (["00", "00", 11, 11, "ff", "ff"], [0, 0, 0, 0, 0, 0]) This works if you use: map { hex $_ } @parts; Although, it might be better to just avoid "local $_" statements like the plague.

Fri Sep 28 13:24:21 2012 BBYRD [...] cpan.org - Correspondence added

This is actually a problem with 00:19:e3:01:0e:72 syntax as well. Not sure what's going on, but using "map { hex $_ }" seems to work. The Cisco style syntax always seems to work.

Fri Sep 28 13:24:22 2012 BBYRD [...] cpan.org - Status changed from 'new' to 'open'

Fri Sep 28 19:44:08 2012 dean [...] fragfest.com.au - Correspondence added

Subject:	Re: [rt.cpan.org #79915] _mac_to_integers: local $_ doesn't play nice with map { hex }
Date:	Sat, 29 Sep 2012 08:24:23 +1300
To:	"bug-NetAddr-MAC [...] rt.cpan.org" <bug-NetAddr-MAC [...] rt.cpan.org>
From:	Dean Hamstead <dean [...] fragfest.com.au>

thanks Brendan, I'll have a look when I'm back in Australia next week Dean On 29/09/2012, at 6:15 AM, "Brendan Byrd via RT" <bug-NetAddr-MAC@rt.cpan.org> wrote: Show quoted text

> Fri Sep 28 13:15:07 2012: Request 79915 was acted upon. > Transaction: Ticket created by BBYRD > Queue: NetAddr-MAC > Subject: _mac_to_integers: local $_ doesn't play nice with map { hex } > Broken in: 0.77 > Severity: Important > Owner: Nobody > Requestors: BBYRD@cpan.org > Status: new > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=79915 > > > > Under certain conditions, "no symbol" MAC parsing fails because of an > interaction between "local $_" and "map { hex }" statements. > > In this case, I was creating a NetAddr::MAC object within a BUILDARGs > method, and every single time, it would fail to parse these kinds of > strings. After some debugging, I found this: > > use Data::Dump 'pp'; > use Devel::SimpleTrace; > > die pp(\@parts, [ map { hex } @parts ]); > > # (["00", "00", 11, 11, "ff", "ff"], [0, 0, 0, 0, 0, 0]) > > This works if you use: > > map { hex $_ } @parts; > > Although, it might be better to just avoid "local $_" statements like > the plague.

Tue Oct 02 20:16:00 2012 dean [...] fragfest.com.au - Correspondence added

i just released 0.78, which i hope will fix it. i dont entirely know what you are doing that you found this issue (so i havent added a test case) - but i have hopefully fixed it nonetheless. if you have time, i would appreciate your further working with me to resolve this problem. see also github https://github.com/djzort/NetAddr-MAC

Tue Oct 02 20:16:02 2012 dean [...] fragfest.com.au - Status changed from 'open' to 'resolved'

Tue Oct 02 21:35:08 2012 $_ = 'spro^^*%*^6ut# [...] &$%*c>#!^!#&!pan.org'; y/a-z.@//cd; print - Correspondence added

On Fri Sep 28 13:24:21 2012, BBYRD wrote: Show quoted text

> This is actually a problem with 00:19:e3:01:0e:72 syntax as well. Not > sure what's going on, but using "map { hex $_ }" seems to work. The > Cisco style syntax always seems to work.

I would be interesting in what perl version you are using, and whether you could provide a script to produce it. hex vs hex $_ should make no difference. If it does, that’s a perl bug. (Sorry for reopening this.)

Tue Oct 02 21:35:09 2012 The RT System itself - Status changed from 'resolved' to 'open'

Tue Oct 02 21:43:17 2012 dean [...] fragfest.com.au - Correspondence added

Message body is not shown because it is too large.

Tue Oct 02 21:43:40 2012 dean [...] fragfest.com.au - Correspondence added

im still not 100% sure how to replicate your original problem.

Tue Oct 02 22:14:00 2012 $_ = 'spro^^*%*^6ut# [...] &$%*c>#!^!#&!pan.org'; y/a-z.@//cd; print - Correspondence added

On Tue Oct 02 21:43:17 2012, djzort wrote: Show quoted text

> On Tue Oct 02 21:35:08 2012, SPROUT wrote:

> > On Fri Sep 28 13:24:21 2012, BBYRD wrote:

> > > This is actually a problem with 00:19:e3:01:0e:72 syntax as well.

> > Not

> > > sure what's going on, but using "map { hex $_ }" seems to work.

> The

> > > Cisco style syntax always seems to work.

> > > > I would be interesting in what perl version you are using, and

> whether

> > you could provide a script > > to produce it. > > > > hex vs hex $_ should make no difference. If it does, that’s a perl > > bug. > > > > (Sorry for reopening this.)

> > Im glad for you to re-open it. > > im using... > > dean@soundwave:~$ perl -v > > This is perl 5, version 14, subversion 2 (v5.14.2) built for > x86_64-linux-gnu-thread-multi > (with 62 registered patches, see perl -V for more detail)

Thank you. But I was actually interested in what the original poster is using.

Tue Oct 02 22:47:01 2012 dean [...] fragfest.com.au - Correspondence added

Subject:	Re: [rt.cpan.org #79915] _mac_to_integers: local $_ doesn't play nice with map { hex }
Date:	Wed, 03 Oct 2012 12:46:30 +1000
To:	bug-NetAddr-MAC [...] rt.cpan.org
From:	Dean Hamstead <dean [...] fragfest.com.au>

oh yes sorry, i didnt realise someone else had entered the conversation. welcome. On 03/10/12 12:14, Father Chrysostomos via RT wrote: Show quoted text

> Queue: NetAddr-MAC > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=79915 > > > On Tue Oct 02 21:43:17 2012, djzort wrote:

>> On Tue Oct 02 21:35:08 2012, SPROUT wrote:

>>> On Fri Sep 28 13:24:21 2012, BBYRD wrote:

>>>> This is actually a problem with 00:19:e3:01:0e:72 syntax as well.

>>> Not

>>>> sure what's going on, but using "map { hex $_ }" seems to work.

>> The

>>>> Cisco style syntax always seems to work.

>>> >>> I would be interesting in what perl version you are using, and

>> whether

>>> you could provide a script >>> to produce it. >>> >>> hex vs hex $_ should make no difference. If it does, that’s a perl >>> bug. >>> >>> (Sorry for reopening this.)

>> >> Im glad for you to re-open it. >> >> im using... >> >> dean@soundwave:~$ perl -v >> >> This is perl 5, version 14, subversion 2 (v5.14.2) built for >> x86_64-linux-gnu-thread-multi >> (with 62 registered patches, see perl -V for more detail)

> > Thank you. But I was actually interested in what the original poster is using. >

Wed Oct 03 10:28:02 2012 BBYRD [...] cpan.org - Correspondence added

On Tue Oct 02 21:35:08 2012, SPROUT wrote: Show quoted text

> > I would be interesting in what perl version you are using, and whether > you could provide a script > to produce it. > > hex vs hex $_ should make no difference. If it does, that’s a perl > bug. > > (Sorry for reopening this.)

You should be able to duplicate this via NetAddr::BridgeID, undoing the code block that works around this bug, and running the single test file. This is going through an around block, and the module itself is pretty minimal, so I'm not sure if it can be shaved down much further. Did you want me to throw in some additional debug information? Summary of my perl5 (revision 5 version 16 subversion 0) configuration: Platform: osname=MSWin32, osvers=4.0, archname=MSWin32-x86-multi-thread uname='Win32 strawberry-perl 5.16.0.1 #1 Mon May 21 22:07:30 2012 i386' config_args='undef' hint=recommended, useposix=true, d_sigaction=undef useithreads=define, usemultiplicity=define useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=undef, use64bitall=undef, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='gcc', ccflags =' -s -O2 -DWIN32 -DPERL_TEXTMODE_SCRIPTS -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -fno-strict-aliasing -mms-bitfi elds', optimize='-s -O2', cppflags='-DWIN32' ccversion='', gccversion='4.6.3', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='long long', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='g++', ldflags ='-s -L"C:\strawberry\perl\lib\CORE" -L"C:\strawberry\c\lib"' libpth=C:\strawberry\c\lib C:\strawberry\c\i686-w64-mingw32\lib libs=-lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lm pr -lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32 perllibs=-lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32 libc=, so=dll, useshrplib=true, libperl=libperl516.a gnulibc_version='' Dynamic Linking: dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags='-mdll -s -L"C:\strawberry\perl\lib\CORE" -L"C:\strawberry\c\lib"' Characteristics of this binary (from libperl): Compile-time options: HAS_TIMES HAVE_INTERP_INTERN MULTIPLICITY PERLIO_LAYERS PERL_DONT_CREATE_GVSV PERL_IMPLICIT_CONTEXT PERL_IMPLICIT_SYS PERL_MALLOC_WRAP PERL_PRESERVE_IVUV PL_OP_SLAB_ALLOC USE_ITHREADS USE_LARGE_FILES USE_LOCALE USE_LOCALE_COLLATE USE_LOCALE_CTYPE USE_LOCALE_NUMERIC USE_PERLIO USE_PERL_ATOF Built under MSWin32 Compiled at May 21 2012 22:15:38 @INC: C:/STRAWBERRY/perl/site/lib/MSWin32-x86-multi-thread C:/STRAWBERRY/perl/site/lib C:/STRAWBERRY/perl/vendor/lib C:/STRAWBERRY/perl/lib .

Wed Oct 03 17:10:27 2012 $_ = 'spro^^*%*^6ut# [...] &$%*c>#!^!#&!pan.org'; y/a-z.@//cd; print - Correspondence added

On Wed Oct 03 10:28:02 2012, BBYRD wrote: Show quoted text

> On Tue Oct 02 21:35:08 2012, SPROUT wrote:

> > > > I would be interesting in what perl version you are using, and whether > > you could provide a script > > to produce it. > > > > hex vs hex $_ should make no difference. If it does, that’s a perl > > bug. > > > > (Sorry for reopening this.)

> > You should be able to duplicate this via NetAddr::BridgeID, undoing the > code block that works around this bug, and running the single test file. > This is going through an around block, and the module itself is pretty > minimal, so I'm not sure if it can be shaved down much further. > > Did you want me to throw in some additional debug information?

What you have provided so far may be enough for me to track this down. Thank you.

Wed Oct 03 17:13:48 2012 $_ = 'spro^^*%*^6ut# [...] &$%*c>#!^!#&!pan.org'; y/a-z.@//cd; print - Correspondence added

On Fri Sep 28 13:15:07 2012, BBYRD wrote: Show quoted text

> Under certain conditions, "no symbol" MAC parsing fails because of an > interaction between "local $_" and "map { hex }" statements. > > In this case, I was creating a NetAddr::MAC object within a BUILDARGs > method, and every single time, it would fail to parse these kinds of > strings. After some debugging, I found this: > > use Data::Dump 'pp'; > use Devel::SimpleTrace; > > die pp(\@parts, [ map { hex } @parts ]); > > # (["00", "00", 11, 11, "ff", "ff"], [0, 0, 0, 0, 0, 0]) > > This works if you use: > > map { hex $_ } @parts; > > Although, it might be better to just avoid "local $_" statements like > the plague.

BTW, local $_ is buggy before 5.16.0, in that it messes with tied $_. Tying $_ might sound like a questionable practice, but it is easy to alias it to a tied variable without realising it: use Config; for (@Config{qw< useithreads mad >}) { do_something(); } So, yes, avoiding local($_) like the plague and using for(expr){...} or for(my$tmp) { ... } instead is generally a good idea. Brendan Byrd is using 5.16.0, so that is probably unrelated.

Wed Oct 03 19:30:09 2012 $_ = 'spro^^*%*^6ut# [...] &$%*c>#!^!#&!pan.org'; y/a-z.@//cd; print - Correspondence added

On Wed Oct 03 10:28:02 2012, BBYRD wrote: Show quoted text

> On Tue Oct 02 21:35:08 2012, SPROUT wrote:

> > > > I would be interesting in what perl version you are using, and whether > > you could provide a script > > to produce it. > > > > hex vs hex $_ should make no difference. If it does, that’s a perl > > bug. > > > > (Sorry for reopening this.)

> > You should be able to duplicate this via NetAddr::BridgeID, undoing the > code block that works around this bug, and running the single test file. > This is going through an around block, and the module itself is pretty > minimal, so I'm not sure if it can be shaved down much further.

It’s a bug in bigint.pm. It globally overrides the hex and oct functions, without emulating the syntax of the built-in functions. So hex($_) does make sense. Loading NetAddr::MAC first would also work around it. This is a pretty serious bug in bigint, as you can’t load it without screwing up hex() calls elsewhere in the program.

Wed Oct 03 19:31:55 2012 dean [...] fragfest.com.au - Correspondence added

Subject:	Re: [rt.cpan.org #79915] _mac_to_integers: local $_ doesn't play nice with map { hex }
Date:	Thu, 04 Oct 2012 09:31:29 +1000
To:	bug-NetAddr-MAC [...] rt.cpan.org
From:	Dean Hamstead <dean [...] fragfest.com.au>

i may be able to work around it by calling ::hex() ? On 04/10/12 09:30, Father Chrysostomos via RT wrote: Show quoted text

> Queue: NetAddr-MAC > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=79915 > > > On Wed Oct 03 10:28:02 2012, BBYRD wrote:

>> On Tue Oct 02 21:35:08 2012, SPROUT wrote:

>>> >>> I would be interesting in what perl version you are using, and whether >>> you could provide a script >>> to produce it. >>> >>> hex vs hex $_ should make no difference. If it does, that’s a perl >>> bug. >>> >>> (Sorry for reopening this.)

>> >> You should be able to duplicate this via NetAddr::BridgeID, undoing the >> code block that works around this bug, and running the single test file. >> This is going through an around block, and the module itself is pretty >> minimal, so I'm not sure if it can be shaved down much further.

> > It’s a bug in bigint.pm. > > It globally overrides the hex and oct functions, without emulating the syntax of the built-in > functions. > > So hex($_) does make sense. Loading NetAddr::MAC first would also work around it. > > This is a pretty serious bug in bigint, as you can’t load it without screwing up hex() calls > elsewhere in the program. >

Wed Oct 03 21:05:39 2012 $_ = 'spro^^*%*^6ut# [...] &$%*c>#!^!#&!pan.org'; y/a-z.@//cd; print - Correspondence added

On Wed Oct 03 19:31:55 2012, djzort wrote: Show quoted text

> i may be able to work around it by calling ::hex() ?

If you mean CORE::hex, yes, that would work. I’ve just been having a look at bigint’s overrides, and they are even more broken than I imagined. :-( Show quoted text

> > On 04/10/12 09:30, Father Chrysostomos via RT wrote:

> > Queue: NetAddr-MAC > > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=79915 > > > > > On Wed Oct 03 10:28:02 2012, BBYRD wrote:

> >> On Tue Oct 02 21:35:08 2012, SPROUT wrote:

> >>> > >>> I would be interesting in what perl version you are using, and

> whether

> >>> you could provide a script > >>> to produce it. > >>> > >>> hex vs hex $_ should make no difference. If it does, that’s a

> perl

> >>> bug. > >>> > >>> (Sorry for reopening this.)

> >> > >> You should be able to duplicate this via NetAddr::BridgeID, undoing

> the

> >> code block that works around this bug, and running the single test

> file.

> >> This is going through an around block, and the module itself is

> pretty

> >> minimal, so I'm not sure if it can be shaved down much further.

> > > > It’s a bug in bigint.pm. > > > > It globally overrides the hex and oct functions, without emulating

> the syntax of the built-in

> > functions. > > > > So hex($_) does make sense. Loading NetAddr::MAC first would also

> work around it.

> > > > This is a pretty serious bug in bigint, as you can’t load it without

> screwing up hex() calls

> > elsewhere in the program. > >

Wed Oct 03 21:09:02 2012 dean [...] fragfest.com.au - Correspondence added

Subject:	Re: [rt.cpan.org #79915] _mac_to_integers: local $_ doesn't play nice with map { hex }
Date:	Thu, 04 Oct 2012 11:08:43 +1000
To:	bug-NetAddr-MAC [...] rt.cpan.org
From:	Dean Hamstead <dean [...] fragfest.com.au>

That seems like it justifies its own bug? Then I can reference the bug number with the fix so people know why we are calling CORE::hex rather than just hex. Detecting if hex() has been overridden will probably be the long way around versus just calling CORE::hex On 04/10/12 11:05, Father Chrysostomos via RT wrote: Show quoted text

> Queue: NetAddr-MAC > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=79915 > > > On Wed Oct 03 19:31:55 2012, djzort wrote:

>> i may be able to work around it by calling ::hex() ?

> > If you mean CORE::hex, yes, that would work. > > I’ve just been having a look at bigint’s overrides, and they are even more broken than I > imagined. :-( >

>> >> On 04/10/12 09:30, Father Chrysostomos via RT wrote:

>>> Queue: NetAddr-MAC >>> Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=79915 > >>> >>> On Wed Oct 03 10:28:02 2012, BBYRD wrote:

>>>> On Tue Oct 02 21:35:08 2012, SPROUT wrote:

>>>>> >>>>> I would be interesting in what perl version you are using, and

>> whether

>>>>> you could provide a script >>>>> to produce it. >>>>> >>>>> hex vs hex $_ should make no difference. If it does, that’s a

>> perl

>>>>> bug. >>>>> >>>>> (Sorry for reopening this.)

>>>> >>>> You should be able to duplicate this via NetAddr::BridgeID, undoing

>> the

>>>> code block that works around this bug, and running the single test

>> file.

>>>> This is going through an around block, and the module itself is

>> pretty

>>>> minimal, so I'm not sure if it can be shaved down much further.

>>> >>> It’s a bug in bigint.pm. >>> >>> It globally overrides the hex and oct functions, without emulating

>> the syntax of the built-in

>>> functions. >>> >>> So hex($_) does make sense. Loading NetAddr::MAC first would also

>> work around it.

>>> >>> This is a pretty serious bug in bigint, as you can’t load it without

>> screwing up hex() calls

>>> elsewhere in the program. >>>

> > >

Thu Oct 04 12:47:24 2012 $_ = 'spro^^*%*^6ut# [...] &$%*c>#!^!#&!pan.org'; y/a-z.@//cd; print - Correspondence added

RT-Send-CC:

rafl [...] debian.org

On Wed Oct 03 21:09:02 2012, djzort wrote: Show quoted text

> That seems like it justifies its own bug?

Well, no bug report is necessary, as I have already fixed the bug. :-) See <http://perl5.git.perl.org/perl.git/commitdiff/9663a7f582d>. I am forwarding this to Florian Ragwitz, the CPAN maintainer, with the hope that he can make a new release soon. Show quoted text

> Then I can reference the bug > number with the fix so people know why we are calling CORE::hex rather > than just hex.

I think this ticket would do, wouldn’t it?

Thu Oct 04 20:39:35 2012 dean [...] fragfest.com.au - Correspondence added

Subject:	Re: [rt.cpan.org #79915] _mac_to_integers: local $_ doesn't play nice with map { hex }
Date:	Fri, 05 Oct 2012 10:39:10 +1000
To:	bug-NetAddr-MAC [...] rt.cpan.org
From:	Dean Hamstead <dean [...] fragfest.com.au>

Im concerned that it may impact olde by popular distributions like rhel/centos but i dont think its sensible for a module to have to check that core functions haven't been overridden. some assumptions have to be made, and thats usually a safe one. On 05/10/12 02:47, Father Chrysostomos via RT wrote: Show quoted text

> Queue: NetAddr-MAC > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=79915 > > > On Wed Oct 03 21:09:02 2012, djzort wrote:

>> That seems like it justifies its own bug?

> > Well, no bug report is necessary, as I have already fixed the bug. :-) See > <http://perl5.git.perl.org/perl.git/commitdiff/9663a7f582d>. > > I am forwarding this to Florian Ragwitz, the CPAN maintainer, with the hope that he can make a > new release soon. >

>> Then I can reference the bug >> number with the fix so people know why we are calling CORE::hex rather >> than just hex.

> > I think this ticket would do, wouldn’t it? >

Thu Oct 04 22:04:26 2012 $_ = 'spro^^*%*^6ut# [...] &$%*c>#!^!#&!pan.org'; y/a-z.@//cd; print - Correspondence added

On Thu Oct 04 20:39:35 2012, djzort wrote: Show quoted text

> Im concerned that it may impact olde by popular distributions like > rhel/centos > > but i dont think its sensible for a module to have to check that core > functions haven't been overridden. some assumptions have to be made, > and > thats usually a safe one.

I know. This is not a nice situation. :-( Show quoted text

> > > On 05/10/12 02:47, Father Chrysostomos via RT wrote:

> > Queue: NetAddr-MAC > > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=79915 > > > > > On Wed Oct 03 21:09:02 2012, djzort wrote:

> >> That seems like it justifies its own bug?

> > > > Well, no bug report is necessary, as I have already fixed the bug.

> :-) See

> > <http://perl5.git.perl.org/perl.git/commitdiff/9663a7f582d>. > > > > I am forwarding this to Florian Ragwitz, the CPAN maintainer, with

> the hope that he can make a

> > new release soon. > >

> >> Then I can reference the bug > >> number with the fix so people know why we are calling CORE::hex

> rather

> >> than just hex.

> > > > I think this ticket would do, wouldn’t it? > >

Mon Jun 02 20:29:46 2014 dean [...] fragfest.com.au - Correspondence added

im going to go ahead and close this as the problem was elsewhere

Mon Jun 02 20:29:47 2014 dean [...] fragfest.com.au - Status changed from 'open' to 'resolved'

Mon Jun 02 20:29:48 2014 dean [...] fragfest.com.au - Fixed in 0.82 added