Thomas Pfau wrote:
I started moving a '__END__' through pack.t to figure out why it wouldn't run. It seemed to be dying without any notice during compilation as only BEGIN blocks would run.
I was about 2/3rds through the file when it stopped running. I commented out the immediate section of code and was able to run what remained. Uncommenting the section caused it to die again.
In that section of code, there are some large floating point constants (1.36514538e67). The VAX range appears to be about 1.7e38. I get the feeling that these are causing perl to crash but it doesn't even print any messages. I have a perl script that prompts for perl code and executes it. If I enter one of these numbers, the script unceremoniously exits. If I try using very large floating point constants on linux, the variable gets assign 'inf' instead.
Is perl not trapping floating point exceptions properly on VMS?
Well, it depends on what you mean by "properly". Doing what linux does presupposes IEEE floating point. Perl on VAX, though it simply can't do IEEE because the format is unavailable, should at least blow up in a visible fashion if asked to represent a value it can't. That's the same thing that would happen in any VMS native language. If you get no indication whatsoever that something misfired under the hood, that's worth noting. What happens of you do this with your D_FLOAT compiled perl:
$ perl -e "$x = 1.36514538e67; print $x;" $ show symbol $status
You can substitute "mcr []miniperl" in the build directory for "perl" if you like.
Anyway, I reconfigured and rebuilt with /G_FLOAT today and op/pack.t passes but some other tests are now failing. On Monday I'll compare the results of the first build with the results of the /G_FLOAT build to see what changed. The tests hadn't completed before I left work today (3:43 to build, will probably take as long to test).
Perl has gotten very big, so it does take a very long time to build and test on older hardware.
