On Tue, 04 Jun 2019 00:14:02 GMT, jkeenan@pobox.com wrote: > The following smoke test indicates that a recent change to blead is > causing failures in t/op/sprintf2.t on FreeBSD-11. > > ##### > http://perl5.test-smoke.org/report/88863 > ##### > > In each of 36 different configurations in the smoke test run, all tests > pass individually, but the file has a whole is graded FAIL. > > ##### > $ cd t; ./perl harness -v op/sprintf2.t;cd - > > ok 1 - the sprintf "%.<number>g" optimization > ok 2 - the sprintf "%.<number>f" optimization > ok 3 - width calculation under utf8 upgrade, length=1 > ... > ok 1698 - special-case %.0f on -4503599627370503 > ok 1699 - croak for very large numeric format results > Dubious, test returned 9 (wstat 2304, 0x900) > All 1699 subtests passed > (less 30 skipped subtests: 1669 okay) > > Test Summary Report > ------------------- > op/sprintf2.t (Wstat: 2304 Tests: 1699 Failed: 0) > Non-zero exit status: 9 > Files=1, Tests=1699, 0 wallclock secs ( 0.20 usr 0.01 sys + 0.16 cusr > 0.11 csys = 0.48 CPU) > Result: FAIL > ##### > > Bisecting with the following command ... > > ##### > perl Porting/bisect.pl --start=e3c1dc81bd --end=9f58603ced --target > t/op/sprintf2.t > ##### > > ... gave this result: > > ##### > ... > good - zero exit from ./perl -Ilib t/op/sprintf2.t > Runner returned 0 for end revision at Porting/bisect.pl line 233. > That took 114 seconds. > ##### > > ... which is not useful. I hypothesized that something is tickling > .t/TEST or ./t perl harness with respect to the failing test (or vice > versa). > > To test this hypothesis, I reviewed 'git log' and noticed two commits > which might have touched sprintf functionality. I built perl at each of > them, saw that one PASS and one FAIL; confirmed the FAIL. > > ##### > commit 027471cf1095f75f273df40310e4647fe1e8a9df > Author: Tony Cook <tony@develop-help.com> > AuthorDate: Wed Mar 20 16:47:49 2019 +1100 > Commit: Tony Cook <tony@develop-help.com> > CommitDate: Mon Jun 3 15:48:34 2019 +1000 > > (perl #133913) limit numeric format results to INT_MAX > > The return value of v?snprintf() is int, and we pay attention to that > return value, so limit the expected size of numeric formats to INT_MAX. > ##### > > Thank you very much. > Jim Keenan > The problem lies in this unit test which was added to t/op/sprintf2.t in the commit in question: ##### # large uvsize needed so the large width is parsed properly # large sizesize needed so the STRLEN check doesn't if ($Config{intsize} == 4 && $Config{uvsize} > 4 && $Config{sizesize} > 4) { eval { my $x = sprintf("%7000000000E", 0) }; like($@, qr/^Numeric format result too large at /, "croak for very large numeric format results"); } ##### If I comment out this test, I get a PASS. So something's amiss with that test in relation to the harness. Thank you very much. -- James E Keenan (jkeenan@cpan.org)Thread Previous | Thread Next