Perl 5.34.0 for OpenVMS x86_64 installation kit available

[Craig A. Berry]

Built with X86_XTOOLS V9.1-A_XG1K and a fair amount of colorful language:

<https://sourceforge.net/projects/vmsperlkit/files/VMSPORTS-X86VMS-PERL534-T0534-0-1.SFX_X86EXE/download>

Note the "T" indicating test in the version number, which seemed
appropriate given I can't run the test suite in a cross compile
environment. That means you are the tester, so if it breaks something
or crashes your system, the test has been successful in identifying a
problem :-). That said, it looks pretty solid with the few small things
I've run with it on 9.1-A.

Have an appropriate amount of fun.

[hb]

The file looks corrupted. It can not be activated and unzip can't look
into it.

[Craig A. Berry]

Hmm. I used the same mechanisms I've always used for Alpha and Itanium
and I did test the self-extracting archive before uploading to
sourceforge. But you're right -- something didn't survive the round
trip. I've replaced it with an ordinary zip file (not self-extracting):

<https://sourceforge.net/projects/vmsperlkit/files/VMSPORTS-X86VMS-PERL534-T0534-0-1.zip/download>

See if that works any better.

[hb]

Worked for me. Using it, I get an unexpected "Hexadecimal number >
0xffffffff non-portable" which I didn't see in perl 5, version 28 on IA64.

[Craig A. Berry]

It's a very old warning (about 20 years). The C code that does the
actual check is here:

<https://perl5.git.perl.org/perl5.git/blob/a31d0367bbf1e97bab6eece95b47ca513e1834a6:/numeric.c#l577>

The check only happens if the size of a Perl integer is greater than 32
bits, so I suspect the difference is that I didn't make 64-bit integers
the default until just a couple of years ago:

<https://perl5.git.perl.org/perl5.git/commit/c6981b9a20742358c4af17bc46ba8d20a1c46d07?f=configure.com>

and the first stable release in which the default changed would have
been Perl 5.32.0. In other words, nothing to do with running on x86.

I think you can turn off that warning by putting

no warnings 'portable';

in the same lexical scope as the code that triggers it.

[hb]

With perl 5, version 28 on IA64, I see:
$ perl -e "my $x=0x100000000;"
Integer overflow in hexadecimal number at -e line 1.
$ perl -e "use bigint; my $x=0x100000000;"
$ perl -e "use warnings; use bigint; my $x=0x100000000;"
$

With perl 5, version 34 on X86, I see:
$ perl -e "my $x=0x100000000;"
$ perl -e "use bigint; my $x=0x100000000;"
$ perl -e "use warnings; use bigint; my $x=0x100000000;"
Hexadecimal number > 0xffffffff non-portable at -e line 1.
$

[Craig A. Berry]

Right, there is harder reckoning when you have 32-bit integers so the
warning you encountered in a 64-bit Perl isn't necessary.

> $ perl -e "use bigint; my $x=0x100000000;"
> $ perl -e "use warnings; use bigint; my $x=0x100000000;"
> $
>
> With perl 5, version 34 on X86, I see:
> $ perl -e "my $x=0x100000000;"
> $ perl -e "use bigint; my $x=0x100000000;"
> $ perl -e "use warnings; use bigint; my $x=0x100000000;"
> Hexadecimal number > 0xffffffff non-portable at -e line 1.

With Perl 5.26.2 on macOS:

$ perl -e 'use warnings; use bigint; my $x=0x100000000;'
Hexadecimal number > 0xffffffff non-portable at -e line 1.

which happens to have 64-bit integers:

$ perl -'V:uvsize'
uvsize='8';

I've never used the bigint extension. It says on the tin, "Integer
constants are created as proper BigInts." I think you may have found
that a hexadecimal constant is not actually being considered an integer
constant. Whether that is a bug or a feature I don't know. It does
have a hex function, which may get you what you want:

$ perl -e "use warnings; use bigint; my $x=hex('0x100000000'); print
qq/$x\n/;"
4294967296

[hb]

I found a workaround: (0xffffffff+1).