Re: overload "0+" doesn't handle integer results

On Mon, 8 Oct 2007 14:01:02 +0200, "Rafael
Garcia-Suarez"
<rgarciasuarezgmail.com> wrote:

> On 08/10/2007, Rafael Garcia-Suarez
<rgarciasuarezgmail.com> wrote:
> > On 08/10/2007, Rick Delaney <rickbort.ca> wrote:
> > > Undoubtedly.  In the meantime here is another
patch to fix a segfault
> > > introduced by the first.
> >
> > Thanks, applied.
> 
> From the smoke tests, it seems that test 531 fails for
builds with

Smoke [5.10.0] 32059 FAIL(F) hp-ux B.11.23/64 gcc (ia64/2
cpu)
http://www.te
st-smoke.org/reports/50698

> -Duse64bitall. I can't test with this configuration.

I did two manual runs with -Duse64bitall on 32068

Linux 2.6.18.8-0.5 x86_64    Xeon(R) CPU E5320 
1.86GHz/1596(4) x86_64  3951 Mb

All tests successful, 70 tests and 758 subtests skipped.
Files=1461, Tests=185010, 512 wallclock secs (258.50 cusr +
35.60 csys = 294.10 CPU)

HP-UX 11.23/64 U   rx1620/64 Itanium 2/1600(2)              
    ia64    2037 Mb

Failed Test       Stat Wstat Total Fail  List of Failed
------------------------------------------------------------
------------------------
../lib/overload.t    2   512   536    2  531 536
 (2 subtests UNEXPECTEDLY SUCCEEDED), 74 tests and 788
subtests skipped.
Failed 1/1460 test scripts. 2/184816 subtests failed.
Files=1460, Tests=184816, 780 wallclock secs (454.83 cusr +
98.65 csys = 553.48 CPU)
Failed 1/1460 test programs. 2/184816 subtests failed.


x1:/pro/3gl/CPAN/perl-current/t 112 > ./perl -I../lib
../lib/overload.t
1..536
ok 1
ok 2
:
:
ok 527
ok 528
ok 529 - numifies to integer
ok 530 - int() numifies only once
not ok 531 - numifies to self
#   Failed test 'numifies to self'
#   at ../lib/overload.t line 1397.
#          got: '6917529027645582112'
#     expected: '6.91752902764558e+18'
ok 532 - int() numifies once when returning self
ok 533 - numifies to numification of other object
ok 534 - int() numifies once when returning other object
ok 535 - returned object numifies too
not ok 536 - numifies to usual reference value
#   Failed test 'numifies to usual reference value'
#   at ../lib/overload.t line 1406.
#          got: '6917529027645582112'
#     expected: '6.91752902764558e+18'
# Looks like you failed 2 tests of 536.


On a side note, I don't like messages like this:

../lib/Module/Build/t/ppm...................................
.....ok 2/12Invalid header block at offset unknown at
../lib/Module/Build/t/ppm.t line 122
Couldn't read chunk at offset unknown at
../lib/Module/Build/t/ppm.t line 122
Read error on tarfile (missing data)
'blib/html/bin/hello.html' at offset unknown at
../lib/Module/Build/t/ppm.t line 122
../lib/Module/Build/t/ppm...................................
.....ok 10/12Invalid header block at offset unknown at
../lib/Module/Build/t/ppm.t line 174
Couldn't read chunk at offset unknown at
../lib/Module/Build/t/ppm.t line 174
Read error on tarfile (missing data)
'blib/html/bin/hello.html' at offset unknown at
../lib/Module/Build/t/ppm.t line 174

Can't those be silenced?

-- 
H.Merijn Brand         Amsterdam Perl Mongers (http://amsterdam.pm.org/
)
using & porting perl 5.6.2, 5.8.x, 5.9.x   on HP-UX
10.20, 11.00, 11.11,
& 11.23, SuSE 10.0 & 10.2, AIX 4.3 & 5.2, and
Cygwin. http://qa.perl.org
http://mirrors.de
velooper.com/hpux/            http://www.test-smoke.org
                        http
://www.goldmark.org/jeff/stupid-disclaimers/

On 08 Oct 2007, at 14:18, H.Merijn Brand wrote:
>
../lib/Module/Build/t/ppm...................................
.....ok  
> 2/12Invalid header block at offset unknown at
../lib/Module/Build/t/ 
> ppm.t line 122
> Couldn't read chunk at offset unknown at
../lib/Module/Build/t/ 
> ppm.t line 122
> Read error on tarfile (missing data)
'blib/html/bin/hello.html' at  
> offset unknown at ../lib/Module/Build/t/ppm.t line 122
>
../lib/Module/Build/t/ppm...................................
.....ok  
> 10/12Invalid header block at offset unknown at
../lib/Module/Build/ 
> t/ppm.t line 174
> Couldn't read chunk at offset unknown at
../lib/Module/Build/t/ 
> ppm.t line 174
> Read error on tarfile (missing data)
'blib/html/bin/hello.html' at  
> offset unknown at ../lib/Module/Build/t/ppm.t line 174
>
> Can't those be silenced?

They can be by setting C<$Archive::Tar::WARN = 0>,
however you probably
don't want to as these are pointing to a real issue; an
.html file is
being used a tar file, which is not quite working
obviously.

This may point to a more serious issue underneath.

--

   Jos Boumans

   How do I prove I'm not crazy to people who are?

On Oct 08 2007, H.Merijn Brand wrote:
> 
> I did two manual runs with -Duse64bitall on 32068
> 
> Linux 2.6.18.8-0.5 x86_64    Xeon(R) CPU E5320 
1.86GHz/1596(4) x86_64  3951 Mb
> 
> All tests successful, 70 tests and 758 subtests
skipped.
> Files=1461, Tests=185010, 512 wallclock secs (258.50
cusr + 35.60 csys = 294.10 CPU)
> 
> HP-UX 11.23/64 U   rx1620/64 Itanium 2/1600(2)         
         ia64    2037 Mb
...
> not ok 531 - numifies to self
> #   Failed test 'numifies to self'
> #   at ../lib/overload.t line 1397.
> #          got: '6917529027645582112'
> #     expected: '6.91752902764558e+18'

The expected value is just

    my $aref = [];
    my $num_val = 0 + $aref;

So it means that a regular reference in numeric context is
returning an
NV or that pp_add is not doing integer math when it should
here.  I
would say that either one is a separate bug.

I'm pretty sure changing the line to

    my $num_val = int($aref);

will make the tests pass without changing the semantic of
the test too
much.  But we could probably use some TODO tests to ensure
that
references in numeric context are always returning IVs.  Or
is there a
platform with pointers bigger than IVs?

-- 
Rick Delaney
rickbort.ca