Skip Menu |
Report information
Id: 132766
Status: resolved
Priority: 0/
Queue: perl5

Owner: Nobody
Requestors: shay <steve.m.hay [at] googlemail.com>
Cc:
AdminCc:

Operating System: (no value)
PatchStatus: (no value)
Severity: low
Type: unknown
Perl Version: (no value)
Fixed In: (no value)



To: perlbug [...] perl.org
From: Steve Hay <steve.m.hay [...] googlemail.com>
Date: Thu, 25 Jan 2018 14:02:58 +0000
Subject: Recent changes to inline.h have broken VC6 build on Windows
Download (untitled) / with headers
text/plain 1.3k
I've just discovered that the VC6 build on Windows is broken: cl -c -nologo -GF -W3 -I..\lib\CORE -I.\include -I. -I.. -DWIN32 -D_CONSOLE -DNO_STRICT -DPERLDLL -DPERL_CORE -O1 -MD -Zi -DNDEBUG -DPERL_EXTERNAL_GLOB -DPERL_IS_MINIPERL -Fo.\mini\av.obj ..\av.c av.c ..\inline.h(551) : error C2059: syntax error : 'bad suffix on number' ..\inline.h(551) : error C2146: syntax error : missing ')' before identifier 'L' ..\inline.h(551) : error C2059: syntax error : 'bad suffix on number' ..\inline.h(551) : error C2059: syntax error : 'bad suffix on number' ..\inline.h(552) : error C2059: syntax error : 'bad suffix on number' ..\inline.h(552) : error C2059: syntax error : 'bad suffix on number' ..\inline.h(552) : error C2059: syntax error : 'bad suffix on number' ..\inline.h(553) : error C2059: syntax error : 'bad suffix on number' ..\inline.h(553) : error C2059: syntax error : 'bad suffix on number' ..\inline.h(600) : error C2061: syntax error : identifier 'S_variant_under_utf8_count' ..\inline.h(600) : error C2059: syntax error : ';' ..\inline.h(600) : error C2059: syntax error : 'type' NMAKE : fatal error U1077: 'cl' : return code '0x2' Stop. It seems that VC6 doesn't understand the "ULL" suffixes on numbers in the chunk of new code in inline.h added by commit 1d2af5744d75143cf7ee8bfd33d4366a95dd1b95 ("Avoid some branches").
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 121b
Please check if this branch (which contains a number of irrelevant commits as well) fixes the problem -- Karl Williamson
From: Tomasz Konojacki <me [...] xenu.pl>
To: perl5-porters [...] perl.org
Subject: Re: [perl #132766] Recent changes to inline.h have broken VC6 build on Windows
Date: Fri, 26 Jan 2018 00:22:44 +0100
Download (untitled) / with headers
text/plain 1.6k
On Thu, 25 Jan 2018 06:04:00 -0800 Steve Hay (via RT) <perlbug-followup@perl.org> wrote: Show quoted text
> I've just discovered that the VC6 build on Windows is broken: > > cl -c -nologo -GF -W3 -I..\lib\CORE -I.\include -I. -I.. -DWIN32 > -D_CONSOLE -DNO_STRICT -DPERLDLL -DPERL_CORE -O1 -MD -Zi -DNDEBUG > -DPERL_EXTERNAL_GLOB -DPERL_IS_MINIPERL -Fo.\mini\av.obj ..\av.c > av.c > ..\inline.h(551) : error C2059: syntax error : 'bad suffix on number' > ..\inline.h(551) : error C2146: syntax error : missing ')' before identifier 'L' > ..\inline.h(551) : error C2059: syntax error : 'bad suffix on number' > ..\inline.h(551) : error C2059: syntax error : 'bad suffix on number' > ..\inline.h(552) : error C2059: syntax error : 'bad suffix on number' > ..\inline.h(552) : error C2059: syntax error : 'bad suffix on number' > ..\inline.h(552) : error C2059: syntax error : 'bad suffix on number' > ..\inline.h(553) : error C2059: syntax error : 'bad suffix on number' > ..\inline.h(553) : error C2059: syntax error : 'bad suffix on number' > ..\inline.h(600) : error C2061: syntax error : identifier > 'S_variant_under_utf8_count' > ..\inline.h(600) : error C2059: syntax error : ';' > ..\inline.h(600) : error C2059: syntax error : 'type' > NMAKE : fatal error U1077: 'cl' : return code '0x2' > Stop. > > It seems that VC6 doesn't understand the "ULL" suffixes on numbers in > the chunk of new code in inline.h added by commit > 1d2af5744d75143cf7ee8bfd33d4366a95dd1b95 ("Avoid some branches").
Do we really want to keep supporting VC6? That compiler is 20 years old, it doesn't work on modern Windows versions and I believe it's the last version of MSVC without proper support of 64-bit integers. I feel that VC6 support is a liability.
From: Leon Timmermans <fawaka [...] gmail.com>
To: Tomasz Konojacki <me [...] xenu.pl>
Date: Fri, 26 Jan 2018 03:09:33 +0100
Subject: Re: [perl #132766] Recent changes to inline.h have broken VC6 build on Windows
CC: Perl5 Porters <perl5-porters [...] perl.org>
Download (untitled) / with headers
text/plain 613b
On Fri, Jan 26, 2018 at 12:22 AM, Tomasz Konojacki <me@xenu.pl> wrote: Show quoted text
>
>> It seems that VC6 doesn't understand the "ULL" suffixes on numbers in >> the chunk of new code in inline.h added by commit >> 1d2af5744d75143cf7ee8bfd33d4366a95dd1b95 ("Avoid some branches").
> > Do we really want to keep supporting VC6? That compiler is 20 years old, > it doesn't work on modern Windows versions and I believe it's the last > version of MSVC without proper support of 64-bit integers. > > I feel that VC6 support is a liability.
The question is really: do we want to keep supporting C89 (long long is a C99ism). Leon
Subject: Re: [perl #132766] Recent changes to inline.h have broken VC6 build on Windows
Date: Fri, 26 Jan 2018 03:30:11 +0100
To: Perl5 Porters <perl5-porters [...] perl.org>
From: Tomasz Konojacki <me [...] xenu.pl>
Download (untitled) / with headers
text/plain 850b
On Fri, 26 Jan 2018 03:09:33 +0100 Leon Timmermans <fawaka@gmail.com> wrote: Show quoted text
> On Fri, Jan 26, 2018 at 12:22 AM, Tomasz Konojacki <me@xenu.pl> wrote:
> >
> >> It seems that VC6 doesn't understand the "ULL" suffixes on numbers in > >> the chunk of new code in inline.h added by commit > >> 1d2af5744d75143cf7ee8bfd33d4366a95dd1b95 ("Avoid some branches").
> > > > Do we really want to keep supporting VC6? That compiler is 20 years old, > > it doesn't work on modern Windows versions and I believe it's the last > > version of MSVC without proper support of 64-bit integers. > > > > I feel that VC6 support is a liability.
> > The question is really: do we want to keep supporting C89 (long long > is a C99ism). > > Leon
Yeah, but it's an *extremely* common extension found in many non-C99 compilers (including the later versions of Visual C++).
From: Karl Williamson <public [...] khwilliamson.com>
Subject: Re: [perl #132766] Recent changes to inline.h have broken VC6 build on Windows
Date: Thu, 25 Jan 2018 21:04:36 -0700
To: Tomasz Konojacki <me [...] xenu.pl>, Perl5 Porters <perl5-porters [...] perl.org>
Download (untitled) / with headers
text/plain 1.3k
On 01/25/2018 07:30 PM, Tomasz Konojacki wrote: Show quoted text
> On Fri, 26 Jan 2018 03:09:33 +0100 > Leon Timmermans <fawaka@gmail.com> wrote: >
>> On Fri, Jan 26, 2018 at 12:22 AM, Tomasz Konojacki <me@xenu.pl> wrote:
>>>
>>>> It seems that VC6 doesn't understand the "ULL" suffixes on numbers in >>>> the chunk of new code in inline.h added by commit >>>> 1d2af5744d75143cf7ee8bfd33d4366a95dd1b95 ("Avoid some branches").
>>> >>> Do we really want to keep supporting VC6? That compiler is 20 years old, >>> it doesn't work on modern Windows versions and I believe it's the last >>> version of MSVC without proper support of 64-bit integers. >>> >>> I feel that VC6 support is a liability.
>> >> The question is really: do we want to keep supporting C89 (long long >> is a C99ism). >> >> Leon
> > Yeah, but it's an *extremely* common extension found in many non-C99 > compilers (including the later versions of Visual C++). >
Nonetheless, until the project decides it won't support C89 anymore, we have to fix bugs like this. And that decision will take a while to make, and there must be some deprecation cycles even if we decide to do it, and so this bug needs to be fixed now. If someone wants to propose requiring C99, it should be brought up on a different thread. My guess is that since we're still coping with the fallout of requiring C89, it will not get a favorable consensus for the time being.
To: perlbug-followup [...] perl.org
Date: Fri, 26 Jan 2018 08:50:42 +0000
Subject: Re: [perl #132766] Recent changes to inline.h have broken VC6 build on Windows
CC: perl5-porters [...] perl.org
From: Steve Hay via perl5-porters <perl5-porters [...] perl.org>
On 25 January 2018 at 17:42, Karl Williamson via RT <perlbug-followup@perl.org> wrote: Show quoted text
> Please check if this branch (which contains a number of irrelevant commits as well) fixes the problem
I assume you mean the smoke-me/khw-variant branch? I tried that and it's better, but still has two problems: 1) inline.h causes warnings: ..\inline.h(629) : warning C4244: '+=' : conversion from 'unsigned __int64 ' to 'unsigned int ', possible loss of data ..\inline.h(733) : warning C4244: '+=' : conversion from 'unsigned __int64 ' to 'unsigned int ', possible loss of data 2) the build still fails, now during Encode: panic: _force_out_malformed_utf8_message should be called only when there are errors found at Makefile.PL line 136. Unsuccessful Makefile.PL(cpan/Encode): code=65280 at ..\make_ext.pl line 518. NMAKE : fatal error U1077: '..\miniperl.exe' : return code '0x2' Stop. I haven't looked into whether such problems (the second in particular) exist on blead with VC6 prior to the inline.h changes anyway. I will check that later and get back to you.
From: Steve Hay via perl5-porters <perl5-porters [...] perl.org>
To: Tomasz Konojacki <me [...] xenu.pl>
Date: Fri, 26 Jan 2018 09:00:36 +0000
Subject: Re: [perl #132766] Recent changes to inline.h have broken VC6 build on Windows
CC: perl5-porters [...] perl.org
On 25 January 2018 at 23:22, Tomasz Konojacki <me@xenu.pl> wrote: Show quoted text
> > > On Thu, 25 Jan 2018 06:04:00 -0800 > Steve Hay (via RT) <perlbug-followup@perl.org> wrote: >
>> I've just discovered that the VC6 build on Windows is broken: >> >> cl -c -nologo -GF -W3 -I..\lib\CORE -I.\include -I. -I.. -DWIN32 >> -D_CONSOLE -DNO_STRICT -DPERLDLL -DPERL_CORE -O1 -MD -Zi -DNDEBUG >> -DPERL_EXTERNAL_GLOB -DPERL_IS_MINIPERL -Fo.\mini\av.obj ..\av.c >> av.c >> ..\inline.h(551) : error C2059: syntax error : 'bad suffix on number' >> ..\inline.h(551) : error C2146: syntax error : missing ')' before identifier 'L' >> ..\inline.h(551) : error C2059: syntax error : 'bad suffix on number' >> ..\inline.h(551) : error C2059: syntax error : 'bad suffix on number' >> ..\inline.h(552) : error C2059: syntax error : 'bad suffix on number' >> ..\inline.h(552) : error C2059: syntax error : 'bad suffix on number' >> ..\inline.h(552) : error C2059: syntax error : 'bad suffix on number' >> ..\inline.h(553) : error C2059: syntax error : 'bad suffix on number' >> ..\inline.h(553) : error C2059: syntax error : 'bad suffix on number' >> ..\inline.h(600) : error C2061: syntax error : identifier >> 'S_variant_under_utf8_count' >> ..\inline.h(600) : error C2059: syntax error : ';' >> ..\inline.h(600) : error C2059: syntax error : 'type' >> NMAKE : fatal error U1077: 'cl' : return code '0x2' >> Stop. >> >> It seems that VC6 doesn't understand the "ULL" suffixes on numbers in >> the chunk of new code in inline.h added by commit >> 1d2af5744d75143cf7ee8bfd33d4366a95dd1b95 ("Avoid some branches").
> > Do we really want to keep supporting VC6? That compiler is 20 years old, > it doesn't work on modern Windows versions and I believe it's the last > version of MSVC without proper support of 64-bit integers. > > I feel that VC6 support is a liability.
I personally agree, and have suggested dropping support before, but the idea didn't get agreement then, and I don't think much has changed since then to change things: https://www.nntp.perl.org/group/perl.perl5.porters/2013/09/msg207597.html
Subject: Re: [perl #132766] Recent changes to inline.h have broken VC6 build on Windows
Date: Fri, 26 Jan 2018 13:40:51 +0000
To: perlbug-followup [...] perl.org
CC: perl5-porters [...] perl.org
From: Steve Hay via perl5-porters <perl5-porters [...] perl.org>
Download (untitled) / with headers
text/plain 1.5k
On 26 January 2018 at 08:50, Steve Hay <steve.m.hay@googlemail.com> wrote: Show quoted text
> On 25 January 2018 at 17:42, Karl Williamson via RT > <perlbug-followup@perl.org> wrote:
>> Please check if this branch (which contains a number of irrelevant commits as well) fixes the problem
> > I assume you mean the smoke-me/khw-variant branch? I tried that and > it's better, but still has two problems: > > 1) inline.h causes warnings: > > ..\inline.h(629) : warning C4244: '+=' : conversion from 'unsigned > __int64 ' to 'unsigned int ', possible loss of data > ..\inline.h(733) : warning C4244: '+=' : conversion from 'unsigned > __int64 ' to 'unsigned int ', possible loss of data > > 2) the build still fails, now during Encode: > > panic: _force_out_malformed_utf8_message should be called only when > there are errors found at Makefile.PL line 136. > Unsuccessful Makefile.PL(cpan/Encode): code=65280 at ..\make_ext.pl line 518. > NMAKE : fatal error U1077: '..\miniperl.exe' : return code '0x2' > Stop. > > I haven't looked into whether such problems (the second in particular) > exist on blead with VC6 prior to the inline.h changes anyway. I will > check that later and get back to you.
With current blead but commit 1d2af5744d75143cf7ee8bfd33d4366a95dd1b95 reverted, problem 1) still occurs anyway (on line 523), but I don't see problem 2) now. So smoke-me/khw-variant fixes the inline.h problem, but introduces some new problem with Encode. I tried the branch with VC++ 2017 too and that works fine, so the Encode problem is probably VC6-specific again.
CC: Tomasz Konojacki <me [...] xenu.pl>, "Perl5 Porters (E-mail)" <perl5-porters [...] perl.org>
To: Steve Hay <steve.m.hay [...] googlemail.com>
Subject: Re: [perl #132766] Recent changes to inline.h have broken VC6 build on Windows
Date: Fri, 26 Jan 2018 09:01:18 -0600
From: "Craig A. Berry" <craig.a.berry [...] gmail.com>
Download (untitled) / with headers
text/plain 1.6k
On Fri, Jan 26, 2018 at 3:00 AM, Steve Hay via perl5-porters <perl5-porters@perl.org> wrote: Show quoted text
> On 25 January 2018 at 23:22, Tomasz Konojacki <me@xenu.pl> wrote:
Show quoted text
>> I feel that VC6 support is a liability.
> > I personally agree, and have suggested dropping support before, but > the idea didn't get agreement then, and I don't think much has changed > since then to change things: > > https://www.nntp.perl.org/group/perl.perl5.porters/2013/09/msg207597.html
It seems to me that things *have* changed since then. If we remove VC6 today, another (almost) five years will have passed between that discussion and the release of 5.28. It's noble to support stuff the vendor has long-since abandoned, but it's reasonable to ask "how long?" I didn't reread every message in that thread, but it seems to me it boiled down to three items: 1.) ActiveState binaries are built with VC6 so it needs to be supported. But this is no longer true. 2.) You need to support VC6 to support developing on Windows XP. Really? People still running Windows XP in 2018 have far worse problems than we can help them with by allowing them to build current Perl releases. 3. You need VC6 to hack the Windows DLL model into an older, simpler form that makes it easier to do certain kinds of low-level debugging. I'm not sure I even understood that correctly, but why should *we* support something that Microsoft has never supported and long-since moved its toolchain in a different direction? So I really don't see any reason to keep it, and removing it now does not prevent people from tinkering with 5.26.x in obsolete environments for as long as they want.
From: Karl Williamson <public [...] khwilliamson.com>
CC: perl5-porters [...] perl.org
Subject: Re: [perl #132766] Recent changes to inline.h have broken VC6 build on Windows
Date: Fri, 26 Jan 2018 09:34:04 -0700
To: Steve Hay <steve.m.hay [...] googlemail.com>, perlbug-followup [...] perl.org
Download (untitled) / with headers
text/plain 1.9k
On 01/26/2018 06:40 AM, Steve Hay via perl5-porters wrote: Show quoted text
> On 26 January 2018 at 08:50, Steve Hay <steve.m.hay@googlemail.com> wrote:
>> On 25 January 2018 at 17:42, Karl Williamson via RT >> <perlbug-followup@perl.org> wrote:
>>> Please check if this branch (which contains a number of irrelevant commits as well) fixes the problem
>> >> I assume you mean the smoke-me/khw-variant branch? I tried that and >> it's better, but still has two problems: >> >> 1) inline.h causes warnings: >> >> ..\inline.h(629) : warning C4244: '+=' : conversion from 'unsigned >> __int64 ' to 'unsigned int ', possible loss of data >> ..\inline.h(733) : warning C4244: '+=' : conversion from 'unsigned >> __int64 ' to 'unsigned int ', possible loss of data >> >> 2) the build still fails, now during Encode: >> >> panic: _force_out_malformed_utf8_message should be called only when >> there are errors found at Makefile.PL line 136. >> Unsuccessful Makefile.PL(cpan/Encode): code=65280 at ..\make_ext.pl line 518. >> NMAKE : fatal error U1077: '..\miniperl.exe' : return code '0x2' >> Stop. >> >> I haven't looked into whether such problems (the second in particular) >> exist on blead with VC6 prior to the inline.h changes anyway. I will >> check that later and get back to you.
> > With current blead but commit 1d2af5744d75143cf7ee8bfd33d4366a95dd1b95 > reverted, problem 1) still occurs anyway (on line 523), but I don't > see problem 2) now. > > So smoke-me/khw-variant fixes the inline.h problem, but introduces > some new problem with Encode. I tried the branch with VC++ 2017 too > and that works fine, so the Encode problem is probably VC6-specific > again. >
Is it the same hardware you're running each OS version on? I looked at the code, and I think the new warnings are bogus. blead gives similar warnings in some places on whatever Windows version dromedary has. The panic I would have to look at it more depth. If it's the same hardware, then I would expect a compiler problem.
From: Steve Hay via perl5-porters <perl5-porters [...] perl.org>
CC: perlbug-followup [...] perl.org, perl5-porters [...] perl.org
To: Karl Williamson <public [...] khwilliamson.com>
Subject: Re: [perl #132766] Recent changes to inline.h have broken VC6 build on Windows
Date: Sat, 27 Jan 2018 11:23:15 +0000
Download (untitled) / with headers
text/plain 2.3k
On 26 January 2018 at 16:34, Karl Williamson <public@khwilliamson.com> wrote: Show quoted text
> On 01/26/2018 06:40 AM, Steve Hay via perl5-porters wrote:
>> >> On 26 January 2018 at 08:50, Steve Hay <steve.m.hay@googlemail.com> wrote:
>>> >>> On 25 January 2018 at 17:42, Karl Williamson via RT >>> <perlbug-followup@perl.org> wrote:
>>>> >>>> Please check if this branch (which contains a number of irrelevant >>>> commits as well) fixes the problem
>>> >>> >>> I assume you mean the smoke-me/khw-variant branch? I tried that and >>> it's better, but still has two problems: >>> >>> 1) inline.h causes warnings: >>> >>> ..\inline.h(629) : warning C4244: '+=' : conversion from 'unsigned >>> __int64 ' to 'unsigned int ', possible loss of data >>> ..\inline.h(733) : warning C4244: '+=' : conversion from 'unsigned >>> __int64 ' to 'unsigned int ', possible loss of data >>> >>> 2) the build still fails, now during Encode: >>> >>> panic: _force_out_malformed_utf8_message should be called only when >>> there are errors found at Makefile.PL line 136. >>> Unsuccessful Makefile.PL(cpan/Encode): code=65280 at ..\make_ext.pl line >>> 518. >>> NMAKE : fatal error U1077: '..\miniperl.exe' : return code '0x2' >>> Stop. >>> >>> I haven't looked into whether such problems (the second in particular) >>> exist on blead with VC6 prior to the inline.h changes anyway. I will >>> check that later and get back to you.
>> >> >> With current blead but commit 1d2af5744d75143cf7ee8bfd33d4366a95dd1b95 >> reverted, problem 1) still occurs anyway (on line 523), but I don't >> see problem 2) now. >> >> So smoke-me/khw-variant fixes the inline.h problem, but introduces >> some new problem with Encode. I tried the branch with VC++ 2017 too >> and that works fine, so the Encode problem is probably VC6-specific >> again. >>
> > Is it the same hardware you're running each OS version on? > > I looked at the code, and I think the new warnings are bogus. blead gives > similar warnings in some places on whatever Windows version dromedary has. > > The panic I would have to look at it more depth. If it's the same hardware, > then I would expect a compiler problem.
Both compilers were running on the same machine running Windows 8.1. I've now tried VC6 and VC14 (VC++ 2015) on a second machine (running Windows 7) and I get the same result - VC6 build panics; VC14 is fine. It could well be a compiler problem, as you say.
Date: Sun, 28 Jan 2018 10:41:04 -0700
Subject: Re: [perl #132766] Recent changes to inline.h have broken VC6 build on Windows
To: Tomasz Konojacki <me [...] xenu.pl>, Perl5 Porters <perl5-porters [...] perl.org>
From: Karl Williamson <public [...] khwilliamson.com>
Download (untitled) / with headers
text/plain 303b
On 01/25/2018 09:04 PM, Karl Williamson wrote: Show quoted text
> Nonetheless, until the project decides it won't support C89 anymore, we > have to fix bugs like this.
And similarly for MSVC6. With that in mind, please test the latest smoke-me/khw-variant, as I have special cased MSVC6, so that it hopefully works.
CC: Tomasz Konojacki <me [...] xenu.pl>, Perl5 Porters <perl5-porters [...] perl.org>
To: Karl Williamson <public [...] khwilliamson.com>
Subject: Re: [perl #132766] Recent changes to inline.h have broken VC6 build on Windows
Date: Mon, 29 Jan 2018 08:29:29 +0000
From: Steve Hay via perl5-porters <perl5-porters [...] perl.org>
Download (untitled) / with headers
text/plain 436b
On 28 January 2018 at 17:41, Karl Williamson <public@khwilliamson.com> wrote: Show quoted text
> On 01/25/2018 09:04 PM, Karl Williamson wrote:
>> >> Nonetheless, until the project decides it won't support C89 anymore, we >> have to fix bugs like this.
> > > And similarly for MSVC6. > > With that in mind, please test the latest smoke-me/khw-variant, as I have > special cased MSVC6, so that it hopefully works.
Yes, that fixes the VC6 build. Thanks.
Date: Mon, 29 Jan 2018 09:17:08 +0000
Subject: Re: [perl #132766] Recent changes to inline.h have broken VC6 build on Windows
To: Karl Williamson <public [...] khwilliamson.com>
CC: Tomasz Konojacki <me [...] xenu.pl>, Perl5 Porters <perl5-porters [...] perl.org>
From: Steve Hay via perl5-porters <perl5-porters [...] perl.org>
Download (untitled) / with headers
text/plain 1.2k
On 29 January 2018 at 08:29, Steve Hay <steve.m.hay@googlemail.com> wrote: Show quoted text
> On 28 January 2018 at 17:41, Karl Williamson <public@khwilliamson.com> wrote:
>> On 01/25/2018 09:04 PM, Karl Williamson wrote:
>>> >>> Nonetheless, until the project decides it won't support C89 anymore, we >>> have to fix bugs like this.
>> >> >> And similarly for MSVC6. >> >> With that in mind, please test the latest smoke-me/khw-variant, as I have >> special cased MSVC6, so that it hopefully works.
> > Yes, that fixes the VC6 build. Thanks.
I get a test failure after building it, though :-/ C:\Dev\Git\perl\t>.\perl harness ../ext/XS-APItest/t/utf8.t ../ext/XS-APItest/t/utf8.t .. 1/? Use of code point 0xFFFFFFFF is not allowed; the permissible max is 0x7FFFFFFF at t/utf8.t line 149. # Tests were run but no plan was declared and done_testing() was not seen. # Looks like your test exited with 255 just after 324. ../ext/XS-APItest/t/utf8.t .. Dubious, test returned 255 (wstat 65280, 0xff00) All 324 subtests passed Test Summary Report ------------------- ../ext/XS-APItest/t/utf8.t (Wstat: 65280 Tests: 324 Failed: 0) Non-zero exit status: 255 Parse errors: No plan found in TAP output Files=1, Tests=324, 0 wallclock secs ( 0.02 usr + 0.03 sys = 0.05 CPU) Result: FAIL
Subject: Re: [perl #132766] Recent changes to inline.h have broken VC6 build on Windows
Date: Mon, 29 Jan 2018 14:01:16 +0000
To: Karl Williamson <public [...] khwilliamson.com>
CC: Tomasz Konojacki <me [...] xenu.pl>, Perl5 Porters <perl5-porters [...] perl.org>
From: Steve Hay via perl5-porters <perl5-porters [...] perl.org>
Download (untitled) / with headers
text/plain 1.4k
On 29 January 2018 at 09:17, Steve Hay <steve.m.hay@googlemail.com> wrote: Show quoted text
> On 29 January 2018 at 08:29, Steve Hay <steve.m.hay@googlemail.com> wrote:
>> On 28 January 2018 at 17:41, Karl Williamson <public@khwilliamson.com> wrote:
>>> On 01/25/2018 09:04 PM, Karl Williamson wrote:
>>>> >>>> Nonetheless, until the project decides it won't support C89 anymore, we >>>> have to fix bugs like this.
>>> >>> >>> And similarly for MSVC6. >>> >>> With that in mind, please test the latest smoke-me/khw-variant, as I have >>> special cased MSVC6, so that it hopefully works.
>> >> Yes, that fixes the VC6 build. Thanks.
> > I get a test failure after building it, though :-/ > > C:\Dev\Git\perl\t>.\perl harness ../ext/XS-APItest/t/utf8.t > ../ext/XS-APItest/t/utf8.t .. 1/? Use of code point 0xFFFFFFFF is not > allowed; the permissible max is 0x7FFFFFFF at t/utf8.t line 149. > # Tests were run but no plan was declared and done_testing() was not seen. > # Looks like your test exited with 255 just after 324. > ../ext/XS-APItest/t/utf8.t .. Dubious, test returned 255 (wstat 65280, 0xff00) > All 324 subtests passed > > Test Summary Report > ------------------- > ../ext/XS-APItest/t/utf8.t (Wstat: 65280 Tests: 324 Failed: 0) > Non-zero exit status: 255 > Parse errors: No plan found in TAP output > Files=1, Tests=324, 0 wallclock secs ( 0.02 usr + 0.03 sys = 0.05 CPU) > Result: FAIL
(I get the same with VC14 too, so this isn't VC6-specific.)
CC: Tomasz Konojacki <me [...] xenu.pl>, Perl5 Porters <perl5-porters [...] perl.org>
Subject: Re: [perl #132766] Recent changes to inline.h have broken VC6 build on Windows
Date: Mon, 29 Jan 2018 11:08:48 -0700
To: Steve Hay <steve.m.hay [...] googlemail.com>
From: Karl Williamson <public [...] khwilliamson.com>
Download (untitled) / with headers
text/plain 1.6k
On 01/29/2018 07:01 AM, Steve Hay wrote: Show quoted text
> On 29 January 2018 at 09:17, Steve Hay <steve.m.hay@googlemail.com> wrote:
>> On 29 January 2018 at 08:29, Steve Hay <steve.m.hay@googlemail.com> wrote:
>>> On 28 January 2018 at 17:41, Karl Williamson <public@khwilliamson.com> wrote:
>>>> On 01/25/2018 09:04 PM, Karl Williamson wrote:
>>>>> >>>>> Nonetheless, until the project decides it won't support C89 anymore, we >>>>> have to fix bugs like this.
>>>> >>>> >>>> And similarly for MSVC6. >>>> >>>> With that in mind, please test the latest smoke-me/khw-variant, as I have >>>> special cased MSVC6, so that it hopefully works.
>>> >>> Yes, that fixes the VC6 build. Thanks.
>> >> I get a test failure after building it, though :-/ >> >> C:\Dev\Git\perl\t>.\perl harness ../ext/XS-APItest/t/utf8.t >> ../ext/XS-APItest/t/utf8.t .. 1/? Use of code point 0xFFFFFFFF is not >> allowed; the permissible max is 0x7FFFFFFF at t/utf8.t line 149. >> # Tests were run but no plan was declared and done_testing() was not seen. >> # Looks like your test exited with 255 just after 324. >> ../ext/XS-APItest/t/utf8.t .. Dubious, test returned 255 (wstat 65280, 0xff00) >> All 324 subtests passed >> >> Test Summary Report >> ------------------- >> ../ext/XS-APItest/t/utf8.t (Wstat: 65280 Tests: 324 Failed: 0) >> Non-zero exit status: 255 >> Parse errors: No plan found in TAP output >> Files=1, Tests=324, 0 wallclock secs ( 0.02 usr + 0.03 sys = 0.05 CPU) >> Result: FAIL
> > (I get the same with VC14 too, so this isn't VC6-specific.) >
So this is a new failure? If so, can you bisect it (starting with 18dcbbd3ae4eee82dc79319c25678e0c7a1088ee, which is just a few commits), or just try reverting the final 3 commits in that branch?
From: Karl Williamson <public [...] khwilliamson.com>
CC: Tomasz Konojacki <me [...] xenu.pl>, Perl5 Porters <perl5-porters [...] perl.org>
Subject: Re: [perl #132766] Recent changes to inline.h have broken VC6 build on Windows
Date: Mon, 29 Jan 2018 15:21:58 -0700
To: Steve Hay <steve.m.hay [...] googlemail.com>
Download (untitled) / with headers
text/plain 2.3k
On 01/29/2018 11:08 AM, Karl Williamson wrote: Show quoted text
> On 01/29/2018 07:01 AM, Steve Hay wrote:
>> On 29 January 2018 at 09:17, Steve Hay <steve.m.hay@googlemail.com> >> wrote:
>>> On 29 January 2018 at 08:29, Steve Hay <steve.m.hay@googlemail.com> >>> wrote:
>>>> On 28 January 2018 at 17:41, Karl Williamson >>>> <public@khwilliamson.com> wrote:
>>>>> On 01/25/2018 09:04 PM, Karl Williamson wrote:
>>>>>> >>>>>> Nonetheless, until the project decides it won't support C89 >>>>>> anymore, we >>>>>> have to fix bugs like this.
>>>>> >>>>> >>>>> And similarly for MSVC6. >>>>> >>>>> With that in mind, please test the latest smoke-me/khw-variant, as >>>>> I have >>>>> special cased MSVC6, so that it hopefully works.
>>>> >>>> Yes, that fixes the VC6 build. Thanks.
>>> >>> I get a test failure after building it, though :-/ >>> >>> C:\Dev\Git\perl\t>.\perl harness ../ext/XS-APItest/t/utf8.t >>> ../ext/XS-APItest/t/utf8.t .. 1/? Use of code point 0xFFFFFFFF is not >>> allowed; the permissible max is 0x7FFFFFFF at t/utf8.t line 149. >>> # Tests were run but no plan was declared and done_testing() was not >>> seen. >>> # Looks like your test exited with 255 just after 324. >>> ../ext/XS-APItest/t/utf8.t .. Dubious, test returned 255 (wstat >>> 65280, 0xff00) >>> All 324 subtests passed >>> >>> Test Summary Report >>> ------------------- >>> ../ext/XS-APItest/t/utf8.t (Wstat: 65280 Tests: 324 Failed: 0) >>>    Non-zero exit status: 255 >>>    Parse errors: No plan found in TAP output >>> Files=1, Tests=324,  0 wallclock secs ( 0.02 usr +  0.03 sys =  0.05 >>> CPU) >>> Result: FAIL
>> >> (I get the same with VC14 too, so this isn't VC6-specific.) >>
> > So this is a new failure?  If so, can you bisect it (starting with > 18dcbbd3ae4eee82dc79319c25678e0c7a1088ee, which is just a few commits), > or just try reverting the final 3 commits in that branch? >
Never mind, I was able to reproduce the problem on dromedary's win32, and I see it is from an unrelated commit that happens to be in the branch you tested, but which hasn't been smoked on windows, and isn't ready to be committed. I didn't realize there would be a windows problem with it, so I just pushed the VC6 patch on this convenient branch. On dromedary, if I revert the unrelated commits, the problem goes away, so I'll push just the related fixes to blead
From: Karl Williamson <public [...] khwilliamson.com>
Date: Tue, 30 Jan 2018 19:03:14 -0700
Subject: Re: [perl #132766] Recent changes to inline.h have broken VC6 build on Windows
To: Steve Hay <steve.m.hay [...] googlemail.com>
CC: perlbug-followup [...] perl.org, perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 2.7k
On 01/27/2018 04:23 AM, Steve Hay wrote: Show quoted text
> On 26 January 2018 at 16:34, Karl Williamson <public@khwilliamson.com> wrote:
>> On 01/26/2018 06:40 AM, Steve Hay via perl5-porters wrote:
>>> >>> On 26 January 2018 at 08:50, Steve Hay <steve.m.hay@googlemail.com> wrote:
>>>> >>>> On 25 January 2018 at 17:42, Karl Williamson via RT >>>> <perlbug-followup@perl.org> wrote:
>>>>> >>>>> Please check if this branch (which contains a number of irrelevant >>>>> commits as well) fixes the problem
>>>> >>>> >>>> I assume you mean the smoke-me/khw-variant branch? I tried that and >>>> it's better, but still has two problems: >>>> >>>> 1) inline.h causes warnings: >>>> >>>> ..\inline.h(629) : warning C4244: '+=' : conversion from 'unsigned >>>> __int64 ' to 'unsigned int ', possible loss of data >>>> ..\inline.h(733) : warning C4244: '+=' : conversion from 'unsigned >>>> __int64 ' to 'unsigned int ', possible loss of data >>>> >>>> 2) the build still fails, now during Encode: >>>> >>>> panic: _force_out_malformed_utf8_message should be called only when >>>> there are errors found at Makefile.PL line 136. >>>> Unsuccessful Makefile.PL(cpan/Encode): code=65280 at ..\make_ext.pl line >>>> 518. >>>> NMAKE : fatal error U1077: '..\miniperl.exe' : return code '0x2' >>>> Stop. >>>> >>>> I haven't looked into whether such problems (the second in particular) >>>> exist on blead with VC6 prior to the inline.h changes anyway. I will >>>> check that later and get back to you.
>>> >>> >>> With current blead but commit 1d2af5744d75143cf7ee8bfd33d4366a95dd1b95 >>> reverted, problem 1) still occurs anyway (on line 523), but I don't >>> see problem 2) now. >>> >>> So smoke-me/khw-variant fixes the inline.h problem, but introduces >>> some new problem with Encode. I tried the branch with VC++ 2017 too >>> and that works fine, so the Encode problem is probably VC6-specific >>> again. >>>
>> >> Is it the same hardware you're running each OS version on? >> >> I looked at the code, and I think the new warnings are bogus. blead gives >> similar warnings in some places on whatever Windows version dromedary has. >> >> The panic I would have to look at it more depth. If it's the same hardware, >> then I would expect a compiler problem.
> > Both compilers were running on the same machine running Windows 8.1. > > I've now tried VC6 and VC14 (VC++ 2015) on a second machine (running > Windows 7) and I get the same result - VC6 build panics; VC14 is fine. > > It could well be a compiler problem, as you say. >
I realized later that a bunch of callers could potentially call the function that's not working on VC6, so I thought it best to confine the workaround to within that function. So, 597ee3f45b478da1456092f63d3ac698ee812786 changed to do that. When you get around to trying VC6 again, you could make sure this hasn't broken it again.
CC: perlbug-followup [...] perl.org, Perl5 Porters <perl5-porters [...] perl.org>
Subject: Re: [perl #132766] Recent changes to inline.h have broken VC6 build on Windows
Date: Wed, 31 Jan 2018 08:22:51 +0000
To: Karl Williamson <public [...] khwilliamson.com>
From: Steve Hay via perl5-porters <perl5-porters [...] perl.org>
On 31 January 2018 at 02:03, Karl Williamson <public@khwilliamson.com> wrote: Show quoted text
> On 01/27/2018 04:23 AM, Steve Hay wrote:
>> >> On 26 January 2018 at 16:34, Karl Williamson <public@khwilliamson.com> >> wrote:
>>> >>> On 01/26/2018 06:40 AM, Steve Hay via perl5-porters wrote:
>>>> >>>> >>>> On 26 January 2018 at 08:50, Steve Hay <steve.m.hay@googlemail.com> >>>> wrote:
>>>>> >>>>> >>>>> On 25 January 2018 at 17:42, Karl Williamson via RT >>>>> <perlbug-followup@perl.org> wrote:
>>>>>> >>>>>> >>>>>> Please check if this branch (which contains a number of irrelevant >>>>>> commits as well) fixes the problem
>>>>> >>>>> >>>>> >>>>> I assume you mean the smoke-me/khw-variant branch? I tried that and >>>>> it's better, but still has two problems: >>>>> >>>>> 1) inline.h causes warnings: >>>>> >>>>> ..\inline.h(629) : warning C4244: '+=' : conversion from 'unsigned >>>>> __int64 ' to 'unsigned int ', possible loss of data >>>>> ..\inline.h(733) : warning C4244: '+=' : conversion from 'unsigned >>>>> __int64 ' to 'unsigned int ', possible loss of data >>>>> >>>>> 2) the build still fails, now during Encode: >>>>> >>>>> panic: _force_out_malformed_utf8_message should be called only when >>>>> there are errors found at Makefile.PL line 136. >>>>> Unsuccessful Makefile.PL(cpan/Encode): code=65280 at ..\make_ext.pl >>>>> line >>>>> 518. >>>>> NMAKE : fatal error U1077: '..\miniperl.exe' : return code '0x2' >>>>> Stop. >>>>> >>>>> I haven't looked into whether such problems (the second in particular) >>>>> exist on blead with VC6 prior to the inline.h changes anyway. I will >>>>> check that later and get back to you.
>>>> >>>> >>>> >>>> With current blead but commit 1d2af5744d75143cf7ee8bfd33d4366a95dd1b95 >>>> reverted, problem 1) still occurs anyway (on line 523), but I don't >>>> see problem 2) now. >>>> >>>> So smoke-me/khw-variant fixes the inline.h problem, but introduces >>>> some new problem with Encode. I tried the branch with VC++ 2017 too >>>> and that works fine, so the Encode problem is probably VC6-specific >>>> again. >>>>
>>> >>> Is it the same hardware you're running each OS version on? >>> >>> I looked at the code, and I think the new warnings are bogus. blead >>> gives >>> similar warnings in some places on whatever Windows version dromedary >>> has. >>> >>> The panic I would have to look at it more depth. If it's the same >>> hardware, >>> then I would expect a compiler problem.
>> >> >> Both compilers were running on the same machine running Windows 8.1. >> >> I've now tried VC6 and VC14 (VC++ 2015) on a second machine (running >> Windows 7) and I get the same result - VC6 build panics; VC14 is fine. >> >> It could well be a compiler problem, as you say. >>
> > I realized later that a bunch of callers could potentially call the function > that's not working on VC6, so I thought it best to confine the workaround to > within that function. So, 597ee3f45b478da1456092f63d3ac698ee812786 changed > to do that. > > When you get around to trying VC6 again, you could make sure this hasn't > broken it again.
It's still working fine, thanks.
RT-Send-CC: perl5-porters [...] perl.org
OP agrees it is fixed -- Karl Williamson
From: demerphq <demerphq [...] gmail.com>
Date: Wed, 31 Jan 2018 23:54:15 +0100
Subject: Re: [perl #132766] Recent changes to inline.h have broken VC6 build on Windows
To: "Craig A. Berry" <craig.a.berry [...] gmail.com>
CC: Steve Hay <steve.m.hay [...] googlemail.com>, Tomasz Konojacki <me [...] xenu.pl>, "Perl5 Porters (E-mail)" <perl5-porters [...] perl.org>
Download (untitled) / with headers
text/plain 1.7k
On 26 January 2018 at 16:01, Craig A. Berry <craig.a.berry@gmail.com> wrote: Show quoted text
> On Fri, Jan 26, 2018 at 3:00 AM, Steve Hay via perl5-porters > <perl5-porters@perl.org> wrote:
>> On 25 January 2018 at 23:22, Tomasz Konojacki <me@xenu.pl> wrote:
>
>>> I feel that VC6 support is a liability.
>> >> I personally agree, and have suggested dropping support before, but >> the idea didn't get agreement then, and I don't think much has changed >> since then to change things: >> >> https://www.nntp.perl.org/group/perl.perl5.porters/2013/09/msg207597.html
> > It seems to me that things *have* changed since then. If we remove > VC6 today, another (almost) five years will have passed between that > discussion and the release of 5.28. It's noble to support stuff the > vendor has long-since abandoned, but it's reasonable to ask "how > long?" > > I didn't reread every message in that thread, but it seems to me it > boiled down to three items: > > 1.) ActiveState binaries are built with VC6 so it needs to be > supported. But this is no longer true. > 2.) You need to support VC6 to support developing on Windows XP. > Really? People still running Windows XP in 2018 have far worse > problems than we can help them with by allowing them to build current > Perl releases. > 3. You need VC6 to hack the Windows DLL model into an older, simpler > form that makes it easier to do certain kinds of low-level debugging. > I'm not sure I even understood that correctly, but why should *we* > support something that Microsoft has never supported and long-since > moved its toolchain in a different direction? > > So I really don't see any reason to keep it, and removing it now does > not prevent people from tinkering with 5.26.x in obsolete environments > for as long as they want.
+1. Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org