From @ppisar

Hello,

I noticed that Devel-PPPort-3.48-again does not pass on i686 and armv7hl
architectures. Their common property is that they are 32-bit architectures where
my perl is is built with use64bitint. I saw this failure with perl 5.28.2 and
5.26.3. Cpantesters noticed it either
<http​://www.cpantesters.org/cpan/report/5cc9cde6-6a34-11e9-9066-e374b0ba08e8>​:

t/threads.t ...... ok
# Test 25 got​: "4294967295" (t/uv.t at line 96)
# Expected​: "-1"
# t/uv.t line 96 is​: ok($ret->[1], -1);
# Test 29 got​: "4294967295" (t/uv.t at line 161)
# Expected​: "-1" (returned length utf8_to_uvchr_buf(""); warnings enabled)
# t/uv.t line 161 is​: ok($ret->[1], -1, "returned length $display; warnings enabled");
# Test 34 got​: "4294967295" (t/uv.t at line 161 fail #2)
# Expected​: "-1" (returned length utf8_to_uvchr_buf("\xc4\xc5"); warnings enabled)
# Test 39 got​: "4294967295" (t/uv.t at line 161 fail #3)
# Expected​: "-1" (returned length utf8_to_uvchr_buf("\xc4"); warnings enabled)
# Test 44 got​: "4294967295" (t/uv.t at line 161 fail #4)
# Expected​: "-1" (returned length utf8_to_uvchr_buf("\xc0\x81"); warnings enabled)
# Test 49 got​: "4294967295" (t/uv.t at line 161 fail #5)
# Expected​: "-1" (returned length utf8_to_uvchr_buf("\xff\x80\x90\x90\x90\xbf\xbf\xbf\xbf\xbf\xbf\xbf\xbf"); warnings enabled)
t/uv.t ...........
Failed 6/52 subtests

-- Petr

From @ppisar

On 2019-04-29, "Petr Pisar (via RT)" <perlbug-followup@​perl.org> wrote​:

I noticed that Devel-PPPort-3.48-again does not pass on i686 and
armv7hl architectures. Their common property is that they are 32-bit
architectures where my perl is is built with use64bitint. I saw this
failure with perl 5.28.2 and 5.26.3. Cpantesters noticed it either
<http​://www.cpantesters.org/cpan/report/5cc9cde6-6a34-11e9-9066-e374b0ba08e8>​:

t/threads.t ...... ok
# Test 25 got​: "4294967295" (t/uv.t at line 96)
# Expected​: "-1"

utf8_to_uvchr_buf() as defined in parts/inc/uv stores (STRLEN)-1 into
its last argument in case of a malformed UTF-8 string. That's what the
failing test performes and is in line with a documented API.

The issue is that STRLEN is unsigned int, i.e. 32-bit unsigned integer,
on those platforms. And when the value is intepreteted by Perl test, it's
handled literally as 4294967295 (after augmenting to IV type that is
64-bit with use64bitint) without special casing (STRLEN)-1 value.

-- Petr

From @atoomic

This should be fixed with the release of 3.49
with the patch from khw

Dual-Life/Devel-PPPort#58

On Mon, 29 Apr 2019 10​:13​:28 -0700, ppisar wrote​:

On 2019-04-29, "Petr Pisar (via RT)" <perlbug-followup@​perl.org>
wrote​:

I noticed that Devel-PPPort-3.48-again does not pass on i686 and
armv7hl architectures. Their common property is that they are 32-bit
architectures where my perl is is built with use64bitint. I saw this
failure with perl 5.28.2 and 5.26.3. Cpantesters noticed it either
<http​://www.cpantesters.org/cpan/report/5cc9cde6-6a34-11e9-9066-
e374b0ba08e8>​:

t/threads.t ...... ok
# Test 25 got​: "4294967295" (t/uv.t at line 96)
# Expected​: "-1"

utf8_to_uvchr_buf() as defined in parts/inc/uv stores (STRLEN)-1 into
its last argument in case of a malformed UTF-8 string. That's what
the
failing test performes and is in line with a documented API.

The issue is that STRLEN is unsigned int, i.e. 32-bit unsigned
integer,
on those platforms. And when the value is intepreteted by Perl test,
it's
handled literally as 4294967295 (after augmenting to IV type that is
64-bit with use64bitint) without special casing (STRLEN)-1 value.

-- Petr

The RT System itself - Status changed from 'new' to 'open'

From @khwilliamson

On 4/29/19 11​:13 AM, Petr Pisar wrote​:

On 2019-04-29, "Petr Pisar (via RT)" <perlbug-followup@​perl.org> wrote​:

I noticed that Devel-PPPort-3.48-again does not pass on i686 and
armv7hl architectures. Their common property is that they are 32-bit
architectures where my perl is is built with use64bitint. I saw this
failure with perl 5.28.2 and 5.26.3. Cpantesters noticed it either
<http​://www.cpantesters.org/cpan/report/5cc9cde6-6a34-11e9-9066-e374b0ba08e8>​:

t/threads.t ...... ok
# Test 25 got​: "4294967295" (t/uv.t at line 96)
# Expected​: "-1"

utf8_to_uvchr_buf() as defined in parts/inc/uv stores (STRLEN)-1 into
its last argument in case of a malformed UTF-8 string. That's what the
failing test performes and is in line with a documented API.

The issue is that STRLEN is unsigned int, i.e. 32-bit unsigned integer,
on those platforms. And when the value is intepreteted by Perl test, it's
handled literally as 4294967295 (after augmenting to IV type that is
64-bit with use64bitint) without special casing (STRLEN)-1 value.

-- Petr

The issue should now be fixed both on cpan and in blead with this commit

commit 721db7b
  Author​: Nicolas R <atoomic@​cpan.org>
  Date​: Mon Apr 29 11​:53​:13 2019 -0600

  sync with cpan release of Devel-PPPort 3.49

The issue indeed was the test code not properly handling the size
mismatch between pointers and ints on these platforms.

From @khwilliamson

Closing this ticket
--
Karl Williamson

@khwilliamson - Status changed from 'open' to 'resolved'