Bug #81503 for Params-Validate: undef is accepted as SCALAR in pure Perl implementation

Wed Nov 28 01:28:46 2012 STEFFENW [...] cpan.org - Ticket created

Subject:

undef is accepted as SCALAR in pure Perl implementation

I run Params::Validate on ActiveStatePerl, undef is accepted as SCALAR. On Linux ist fails correctly. Looks like there is a difference between pure Perl and XS implementation.

Sun Jan 06 16:33:21 2013 DROLSKY [...] cpan.org - Correspondence added

On Wed Nov 28 01:28:46 2012, STEFFENW wrote: Show quoted text

> I run Params::Validate on ActiveStatePerl, undef is accepted as SCALAR. > On Linux ist fails correctly. > > Looks like there is a difference between pure Perl and XS

implementation. I wrote a simple test for this and could not reproduce the failure you specified. The test is attached.

Subject:

33-scalar-undef.t

use strict; use warnings; use Params::Validate qw( validate SCALAR ); use Test::More; use Test::Fatal; like( exception { foo( x => undef ) }, qr/was an 'undef'/, 'cannot pass undef when type is SCALAR' ); done_testing(); sub foo { validate( @_, { x => { type => SCALAR } } ); }

Sun Jan 06 16:33:22 2013 The RT System itself - Status changed from 'new' to 'open'

Mon Jan 07 04:08:16 2013 STEFFENW [...] cpan.org - Correspondence added

That test runs on my system also correctly. Going to find an example.

Tue Jan 08 15:04:26 2013 STEFFENW [...] cpan.org - Correspondence added

I checked that on my computer. The folling test runs perfectly n times. Andreas König gave me a hint. The problem is the perl version. If it runs on perl 5.17 the hash key randomization kills 50 % of that tests. -------------------------------------------------------------------- use strict; use warnings; use Params::Validate qw( validate_with SCALAR ARRAYREF ); use Test::More; use Test::Fatal; like( exception { foo( { x => undef, y => undef } ) }, qr{ \Qwas an 'undef'\E .*? \Qtypes: scalar\E }xms, 'cannot pass undef when type is SCALAR' ); done_testing(); sub foo { validate_with( params => shift, spec => { x => { type => ARRAYREF, }, y => { type => SCALAR, }, }, ); }

Tue Jan 08 15:05:56 2013 STEFFENW [...] cpan.org - Correspondence added

Thank you for helping to fix my tests.

Tue Jan 08 15:05:56 2013 STEFFENW [...] cpan.org - Status changed from 'open' to 'resolved'

Mon Jan 14 14:51:37 2013 autarch [...] urth.org - Correspondence added

Subject:	Re: [rt.cpan.org #81503] undef is accepted as SCALAR in pure Perl implementation
Date:	Mon, 14 Jan 2013 13:51:27 -0600 (CST)
To:	Steffen Winkler via RT <bug-Params-Validate [...] rt.cpan.org>
From:	Dave Rolsky <autarch [...] urth.org>

On Tue, 8 Jan 2013, Steffen Winkler via RT wrote: Show quoted text

> Andreas König gave me a hint. The problem is the perl version. If it > runs on perl 5.17 the hash key randomization kills 50 % of that tests. > > -------------------------------------------------------------------- > > use strict; > use warnings; > > use Params::Validate qw( validate_with SCALAR ARRAYREF ); > > use Test::More; > use Test::Fatal; > > like( > exception { foo( { x => undef, y => undef } ) }, > qr{ \Qwas an 'undef'\E .*? \Qtypes: scalar\E }xms, > 'cannot pass undef when type is SCALAR' > );

Well, that's just cause half the time it's failing out because of the "x" param being wrong first. There's no bug here other than in your test. You're passing two failures together and expecting a specific one to be reported, but there's nothing in the PV docs guaranteeing a specific order of evaluation for constraints. -dave /*============================================================ http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) ============================================================*/

Mon Jan 14 14:51:38 2013 The RT System itself - Status changed from 'resolved' to 'open'

Mon Jan 14 14:52:33 2013 autarch [...] urth.org - Correspondence added

Subject:	Re: [rt.cpan.org #81503] undef is accepted as SCALAR in pure Perl implementation
Date:	Mon, 14 Jan 2013 13:52:17 -0600 (CST)
To:	"autarch [...] urth.org via RT" <bug-Params-Validate [...] rt.cpan.org>
From:	Dave Rolsky <autarch [...] urth.org>

On Mon, 14 Jan 2013, autarch@urth.org via RT wrote: Show quoted text

> Well, that's just cause half the time it's failing out because of the "x" > param being wrong first. > > There's no bug here other than in your test. You're passing two failures > together and expecting a specific one to be reported, but there's nothing > in the PV docs guaranteeing a specific order of evaluation for > constraints.

And then looking at your next comment I think you figured this out. Doh. I assume I can close this now. -dave /*============================================================ http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) ============================================================*/

Sun Jan 20 11:11:59 2013 DROLSKY [...] cpan.org - Status changed from 'open' to 'resolved'