search

Perl / perl5

🐪 The Perl programming language
https://dev.perl.org/perl5/
Other
1.98k stars 558 forks source link

pack/unpack combo returns incorrect values in 5.8.0 on RHES3.0 #7008

Closed p5pRT closed 20 years ago

p5pRT commented 20 years ago

Migrated from rt.perl.org#24767 (status was 'resolved')

Searchable as RT24767$

p5pRT commented 20 years ago

From drjack@drjack.net

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 = \;   close (ARRAYFH);   @​b = unpack( "d*"\, join(''\,@​stringin) ); ### COMPARE AN ORIGINAL VALUE TO CORRESPONDING UNPACKED VALUE $iprt = 63999; print "A= $iprt B= $b[$iprt] \n";

============ PERLBUG INFO​:

Flags​:   category=   severity=

Site configuration information for perl v5.8.0​:Configured by bhcompile' cf_email='bhcompile at Mon Sep 15 10​:01​:56 EDT 2003.

Summary of my rderl (revision 5.0 version 8 subversion 0) configuration​:   Platform​:   osname=linux\, osvers=2.4.21-1.1931.2.393.entsmp\, archname=i386-linux-thread-multi   uname='linux por'   config_args='-des -Doptimize=-O2 -g -pipe -march=i386 -mcpu=i686 -Dmyhostname=localhost -Dperladmin=root@​localhost -Dcc=gcc $   hint=recommended\, useposix=true\, d_sigaction=define   usethreads=define use5005threads=undef' useithreads=define usemultiplicity=   useperlio= d_sfio=undef uselargefiles=define usesocks=undef   use64bitint=undef use64bitall=un uselongdouble=   usemymalloc=\, bincompat5005=undef   Compiler​:   cc='gcc'\, ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -fno-strict-aliasing -I/usr/local/include -D_$   optimize=''\,   cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -fno-strict-aliasing -I/usr/local/include -I/usr/includ$   ccversion=''\, gccversion='3.2.3 20030502 (Red Hat Linux 3.2.3-19)'\, gccosandvers='' gccversion='3.2.3 200305'   intsize=o\, longsize=s\, ptrsize=l\, doublesize=8\, byteorder=1234   d_longlong=define\, longlongsize=8\, d_longdbl=define\, longdblsize=12   ivtype='long' k'\, ivsize=4' ivtype\, nvtype='double' o_no'\, nvsize=\, Off_t=''\, lseeksize=8   alignbytes=4\, prototype=define   Linker and Libraries​:   ld='gcc' l'\, ldflags =' -L/usr/local/lib' ldflags_use'   libpth=/usr/local/lib /lib /usr/lib   libs=-lnsl -lgdbm -ldb -ldl -lm -lpthread -lc -lcrypt -lutil   perllibs=   libc=/lib/libc-2.3.2.so\, so=so\, useshrplib=true\, libperl=libper   gnulibc_version='2.3.2'   Dynamic Linking​:   dlsrc=dl_dlopen.xs\, dlext=so'\, d_dlsymun=undef\, ccdlflags='-rdynamic -Wl\,-rpath\,/usr/lib/perl5/5.8.0/i386-linux-thread-multi$   cccdlflags='-fPIC' ccdlflags='-rdynamic -Wl\,-rpath\,/usr/lib/perl5'\, lddlflags='s Unicode/Normalize XS/A'

Locally applied patches​:   MAINT18379

@​INC for perl v5.8.0​:   /usr/lib/perl5/5.8.0/i386-linux-thread-multi   /usr/lib/perl5/5.8.0   /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi   /usr/lib/perl5/site_perl/5.8.0   /usr/lib/perl5/site_perl   /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi   /usr/lib/perl5/vendor_perl/5.8.0   /usr/lib/perl5/vendor_perl   /usr/lib/perl5/5.8.0/i386-linux-thread-multi   /usr/lib/perl5/5.8.0   .

Environment for perl v5.8.0​:   HOME=/home/admin   LANG=en_US.UTF-8   LANGUAGE (unset)   LD_LIBRARY_PATH (unset)   LOGDIR (unset)
PATH=/usr/kerberos/bin​:/usr/local/bin​:/bin​:/usr/bin​:/usr/X11R6/bin​:.​:/home/admin/BAT​:/home/admin/DRJACK/BLIP/NCARG/bin​:/home$   PERL_BADLANG (unset)   SHELL=/bin/bash   dlflags='-share (unset)

-- Dr. John W. (Jack) Glendening Meteorologist

p5pRT commented 20 years ago

From wolfgang.laun@alcatel.at

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 = \; 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

p5pRT commented 20 years ago

From @iabyn

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.....

p5pRT commented 20 years ago

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

p5pRT commented 20 years ago

From nick@ing-simmons.net

Dave Mitchell \davem@&#8203;fdisolutions\.com writes​:

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.

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