[perl #24767] pack/unpack combo returns incorrect values in 5 .8.0 on RHES3.0

[Laun Wolfgang]

> Dr. John W. Glendening wrote on # 28 Dec 2003 07:52:17 -0000:
>
> I find that a simple pack/unpack combination fails to return the
> original FP number when running perl 5.8.0 on a RHES3.0 Linux system.
> The test program that I use has correctly worked on many varieties of
> perl and OSes, including SGI OS as well as Linux, and is attached at the
> end, as is the perlbug info. But on this system the output line which
> compares an original value to the corresponding unpacked value reads:
> A= 63999 B= 2.9076947013346e-17
> instead of the correct
> A= 63999 B= 63999
>
> =========
> PROGRAM:
> =========
> #! /usr/local/bin/perl -w
> #### TEST ARRAY READ/WRITE TO FILE USING PACK/UNPACK #####
> ### CREATE TEST ARRAY WITH VALUE EQUAL TO ITS INDEX
> $npt = 64000;
> for ( $ipt=0; $ipt<$npt; $ipt++ )
> { $a[$ipt] = $ipt; }
> ### PACK ARRAY AND WRITE TO FILE
> `rm -f tmp.test.pack`;
> open ( ARRAYFH, ">>tmp.test.pack");
> $stringout = pack( "d*",@a );
> printf ARRAYFH "%s", $stringout;
> close (ARRAYFH);
> ### READ FROM FILE AND UNPACK ARRAY
> open ( ARRAYFH, "<tmp.test.pack");
> @stringin = <ARRAYFH>;
> close (ARRAYFH);
> @b = unpack( "d*", join('',@stringin) );
> ### COMPARE AN ORIGINAL VALUE TO CORRESPONDING UNPACKED VALUE
> $iprt = 63999;
> print "A= $iprt B= $b[$iprt] \n";
>

An ESPish ls -l tmp.test.pack revealed to me that the file size is 635121
(and not 512000 = 8*64000). The 8 bytes at offset 511992 are identical
to what you get when you pack( "d", 2.9076947013346e-17) on some ix86 box.

I am too ignorant to make any guesses why the file was written
UTF-8-ish. Moreover, the perlbug info got messed up some; perhaps
the environment setting LANG=en_US.UTF-8 may have contributed to that.
(I could reproduce the B=2.9...e-17 output by explicitly using ">>:utf8"
and "<:utf8" in the open calls.)

Whether unpack should warn when certain unpack codes are applied to
a SV where DO_UTF8(sv) is true, is another question. Any opinions?
(I'd say no, but I am biased ;-)

Kind regards
Wolfgang

[Dave Mitchell]

On Tue, Dec 30, 2003 at 08:07:05AM +0100, LAUN Wolfgang wrote:
> I am too ignorant to make any guesses why the file was written
> UTF-8-ish. Moreover, the perlbug info got messed up some; perhaps
> the environment setting LANG=en_US.UTF-8 may have contributed to that.
> (I could reproduce the B=2.9...e-17 output by explicitly using ">>:utf8"
> and "<:utf8" in the open calls.)

This is a well-known interaction between perl 5.8.0, and Redhat 9's (and
8's?) default setting of LANG to be something.UTF-8. This is fixed in
5.8.1, or can be worked around in 5.8.0 by setting LANG to eg, en_US.

> Whether unpack should warn when certain unpack codes are applied to
> a SV where DO_UTF8(sv) is true, is another question. Any opinions?
> (I'd say no, but I am biased ;-)

No idea.

--
Thank God I'm an atheist.....

[Nick Ing-Simmons]

Hmm, I _think_ that unpack is a candidate for SvPVbyte type warning,
but I need to ponder it some more.