Skip Menu |

This queue is for tickets about the Module-ScanDeps CPAN distribution.

Report information
The Basics
Id: 55746
Status: resolved
Priority: 0/
Queue: Module-ScanDeps

People
Owner: Nobody in particular
Requestors: zefram [...] fysh.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: 0.97



Subject: hash-as-condition bug in Module::ScanDeps::DataFeed
Date: Sat, 20 Mar 2010 19:38:24 +0000
To: bug-Module-ScanDeps [...] rt.cpan.org
From: Zefram <zefram [...] fysh.org>
There's a bug in Module::ScanDeps::DataFeed where it uses a hash variable in a truth-value context. This isn't a well-behaved operation, and empirically it causes M:SD to fail quite unnecessarily on Perl 5.8.1/2. The conditional is actually not required at all. Attached patch fixes. -zefram

Message body is not shown because sender requested not to inline it.

On Sat Mar 20 15:39:18 2010, zefram@fysh.org wrote: Show quoted text
> The conditional is actually not required at all. Attached patch fixes.
I agree that this check is bogus. Show quoted text
> There's a bug in Module::ScanDeps::DataFeed where it uses a hash variable > in a truth-value context. This isn't a well-behaved operation, and
Why do you think this isn't "well-behaved"? Checking a %hash for non-emptiness with if (%hash) { ... } is perfectly OK (unless you're on an ancient version of Perl).
Subject: Re: [rt.cpan.org #55746] hash-as-condition bug in Module::ScanDeps::DataFeed
Date: Mon, 22 Mar 2010 10:13:31 +0000
To: RSCHUPP via RT <bug-Module-ScanDeps [...] rt.cpan.org>
From: Zefram <zefram [...] fysh.org>
RSCHUPP via RT wrote: Show quoted text
>(unless you're on an ancient version of Perl).
Counting 5.8.2 as ancient, yes. I like to test my modules against moderately ancient Perls, back to 5.6.1, for a couple of reasons. One is because there are plenty of companies using such versions in production. (<sue@cpan.org> was telling me a couple of days ago about her company's plans to upgrade from 5.6.1 to 5.8.9.) Another is because the testing sometimes uncovers module bugs that are masked by core implementation details that change between versions. (That is, the module may be buggy for all core versions, but the bug only shows up on some versions.) For this purpose, it's nice to keep as many supporting modules as reasonably possible, and especially toolchain modules, portable to older Perl versions. -zefram
On Mon Mar 22 06:13:45 2010, zefram@fysh.org wrote: Show quoted text
> RSCHUPP via RT wrote:
> >(unless you're on an ancient version of Perl).
> > Counting 5.8.2 as ancient, yes. I like to test my modules against
Sorry, you didn't answer my question: why do you think that "if (%hash) { ... }" isn't "well-behaved"? I checked perldata(1) for 5.8.1 and 5.6.1 (as well 5.10.1). All state: If you evaluate a hash in scalar context, it returns false if the hash is empty. If there are any key/value pairs, it returns true [...] Also, could you be a little more specific about actual failures caused by the "... if %Config::Config"?
Subject: Re: [rt.cpan.org #55746] hash-as-condition bug in Module::ScanDeps::DataFeed
Date: Mon, 22 Mar 2010 21:27:58 +0000
To: RSCHUPP via RT <bug-Module-ScanDeps [...] rt.cpan.org>
From: Zefram <zefram [...] fysh.org>
RSCHUPP via RT wrote: Show quoted text
>why do you think that "if (%hash) { ... }" isn't "well-behaved"?
I'm mildly surprised to see that it's documented to behave the way you expect, because I'd got the impression that that wasn't really intended until pretty recently. Seems to be osmotic knowledge to the effect that hash in scalar context has variable behaviour, and I didn't question that when I found it empirically misbehaving. But on now looking more closely, I have a much more precise answer for you. In 5.8.2, there is a specific bug in the handling of hash-as-scalar for tied hashes. The nature of the bug is that the scalarification looks at the underlying hash, ignoring the tie magic. So if you started with an empty hash, as you almost always would, the hash in scalar context would return false regardless of what the tie magic claims is in the hash. %Config::Config is tied. The bug is fixed in 5.8.3, as described in perl583delta. Show quoted text
>Also, could you be a little more specific about actual failures >caused by the "... if %Config::Config"?
With the condition always being false (on 5.8.2), $dl_ext there ends up being undef. When that gets used as part of the generated filenames to look at, it means that all the filenames considered are wrong, so _dl_mod2filename() never finds any of the .so files. Those files are therefore missing from the output of scan_deps_runtime(). This gets picked up in t/7-check-dynaloader.t: $ PERL5LIB=$PWD/blib/arch:$PWD/blib/lib perl -w t/7-check-dynaloader.t 1..3 ok 1 - Path for Cwd.pm or File/Glob.pm found not ok 2 - we have some key that looks like it pulled in the Cwd or Glob shared lib # Failed test 'we have some key that looks like it pulled in the Cwd or Glob shared lib' # at t/7-check-dynaloader.t line 37. Use of uninitialized value in substitution (s///) at t/7-check-dynaloader.t line 40. Use of uninitialized value in hash element at t/7-check-dynaloader.t line 42. Use of uninitialized value in hash element at t/7-check-dynaloader.t line 42. not ok 3 - the full bundle path we got looks legit # Failed test 'the full bundle path we got looks legit' # at t/7-check-dynaloader.t line 42. # got: undef # expected: '/home/zefram/usr/perl/perl_install/perl-5.8.2-i32-f52/lib/5.8.2/i386-linux-thread-multi/' # Looks like you failed 2 tests of 3. -zefram
On Mon Mar 22 17:28:12 2010, zefram@fysh.org wrote: Show quoted text
> In 5.8.2, there is a specific bug in the handling of hash-as-scalar > for > tied hashes. The nature of the bug is that the scalarification looks > at
Ah yes, correct behaviour of "if (%hash) ..." for a tied %hash came indeed in non-ancient times (can one call early 5.8.x "medieval"?). Thanks for your analysis - don't get me started on tied hashes: most XS modules will break when presented with (a reference to) a tied hash instead of a "real" hash. That's because you have to use different functions from XS (in certain situations). I think the conditional was perhaps meant to test for the existence of %Config::Config (PAR and PAR::Packer sometimes play games by directly manipulating %INC, so that after a successful "use Config" you still can't be sure that Config.pm has actually been loaded). But that's not the way to test for that. Anyway, I just committed your patch, will be in the next release.