CPAN test problem

cmac has asked for the wisdom of the Perl Monks concerning the following question:

My CPAN module takes an IP4 address as its operand, and checks its operand as follows:
1) if the scalar is 4 bytes long, it's taken as a packed 32-bit binary value,
2) otherwise it is syntax checked as a "dotted quad", as in '1.2.3.4'.

An operand that fails these tests results in a return value of '**'.
An operand that passes but is not in the database returns '??'.
Other operands return country codes, like 'US'.

The tests for the module include these:

is ($ipw->getcc(0), '**', "getcc(0) should return **");
is ($ipw->getcc(999), '**', "getcc(999) should return **");
# string 1000 is equivalent to '49.48.48.48' which is not covered
is ($ipw->getcc(1000), '??', "getcc(1000) should return ??");
# string 9999 is equivalent to '57.57.57.57'
is ($ipw->getcc(9999), 'EU', "getcc(9999) should return EU");
is ($ipw->getcc(10000), '**', "getcc(10000) should return **");
[download]

These tests assume that Perl stores the constants 0, 999, 1000, 9999, and 10000 as strings. They pass on all CPAN testers' systems except one (so far).

On that system all of the above tests return '??'. Click here to see the FAIL report.

The only explanation that I can think of is that the numeric constants above are stored in 32-bit form.

Is it possible to build or condition a perl system to do that?
If so, should such a system be used for CPAN testing?

This problem can be worked around by executing alternate tests that use '0' ... '10000' if length(0)>1, but it would be nice if someone could comment on this diagnosis first.

Thanks,
cmac

Comment on CPAN test problem Select or Download Code

Replies are listed 'Best First'.
Re: CPAN test problem by BrowserUk (Patriarch) on Apr 11, 2010 at 19:26 UTC
This problem can be worked around by executing alternate tests that use '0' ... '10000' if length(0)>1, Why not just quote the constants and have done with it? Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. "I'd rather go naked than blow up my ass"	[reply]
Re^2: CPAN test problem by cmac (Monk) on Apr 11, 2010 at 20:28 UTC
Stubbornness? The search for understanding of as many things as possible? Stuck in the house by a nasty rainstorm?	[reply]
Re: CPAN test problem by cdarke (Prior) on Apr 12, 2010 at 07:34 UTC
If you have a look at the FAIL report you will see: `cygwin-thread-multi-64int` [download] which might explain a few things.. Update: if the scalar is 4 bytes long Also in the FAIL report is: `ivsize=8` Update2: I tried to install your module on 64-bit Windows. First it failed because you are using Build, and that failed calling Probe::Perl, which is not in the dependency list. Using cpanp hung, so I tried cpan and install, that failed because Build tried to call 'make', and it should be 'nmake'. So I tried again manually now that Build had been installed. The README file said to type "Build make" but that said "No action 'make' defined". So I tried "Build test" and that failed trying to load bufferoverflowU.lib - which is a well-known issue on Windows. Normally I would edit the Makefile, but Build is not creating one. At that point I gave up.	[reply] [d/l] [select]
Re^2: CPAN test problem by cmac (Monk) on Apr 12, 2010 at 16:59 UTC
Thank you for trying to install IP::World. This is the first module for which I've used Module::Build, and other problems have prevented testing from getting very far on Windows. Probe::Perl is definitely in the 'configure_requires' dependency list in Build.PL of version 0.33. I have changed from Module::Build=>0.36 in 'build_requires' to Module::Build=>0.3607 in 'configure_requires' which may help get the whole thing off to a better start. './Build make' in README was dumb of me. I've changed it to './Build' for 0.34. Sorry. The bufferoverflowU.lib business seems to be well-known as you say, but I wasn't able to find a solution that a module author can use. Do you know of anything I can do to work around this? Build will only produce a Makefile if instructed to do so. Do I need to do this to help users deal with the bufferoverflowU.lib problem? May I send you a 0.34 package to try before I upload it to CPAN? This would be in the next day or two. Thanks, cmac	[reply]
Re^3: CPAN test problem by syphilis (Archbishop) on Apr 13, 2010 at 07:28 UTC
The bufferoverflowU.lib business seems to be well-known as you say, but I wasn't able to find a solution that a module author can use There's not much a module author can do about this - nor is it the responsibility of a module author to deal with this. IIUC, this is something that cdarke should attend to - by removing "bufferoverflowU.lib" from the "libs" and "perllibs" entries in lib/Config_heavy.pl. The problem is, I believe, simply that perl's configuration info is misconfigured (duh :-) for the particular compiler that cdarke has chosen to use, and the only person in a position to correct this is cdarke. Another solution would be for cdarke to switch to using the compiler that built perl in the first place. Then no amendments to Config_heavy.pl would be needed. Cheers, Rob	[reply]