Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!ames!haven!uvaarpa!mmdf From: eichin@athena.mit.edu (Mark W. Eichin) Newsgroups: comp.lang.perl Subject: re: perl bugs in pl41 (specifically: ^ ~ and Configure) Message-ID: <1990Dec11.133550.27284@uvaarpa.Virginia.EDU> Date: 11 Dec 90 13:35:50 GMT Sender: mmdf@uvaarpa.Virginia.EDU (Uvaarpa Mail System) Reply-To: eichin@athena.mit.edu Organization: The Internet Lines: 84 Mr. Peterson (and other perl-users): First, please pardon me if this seems to ramble, I've been adding bits and pieces of further info on these compiler problems as I acquire them. Summary: Configure's cast_neg test appears to be incorrect, and the result of this behavior isn't caught by any of the test scripts. I tried your example |>printf (" %x, %x, %x, %x\n", 0xffffffff, 0xf0000000, 0x81234567, ~0xffff); |>printf (" %x, %x, %x\n", 0xfffffff<<4, 15 << 28, ~1); |>$a = 0xffff0000 & 7; $b = 15 << 28 & 7; print " a is $a; b is $b\n"; under PL41 on all platforms I've built it on, and I've also seen strange things. I originally noticed this class of bug (~ ^ and other bitwise things) when porting Dennis Ferguson's DESTOO implementation of DES to perl (it was easy... I might even be able to post a perl script which performs the edits, so as not to violate (1) his copyright (2) US State Department export regulations)... os: IBM PC/RT AOS 4.3 (Athena 7.1) cc: MetaWare hc2.1y -Hon=read_only_strings -Z -g -O ffffffff, f0000000, 81234567, 0 fffffff0, f0000000, 0 a is ; b is (This version also fails any of the lib.big tests involving negative numbers, which I've reduced to the example ./perl -e 'printf "%x\n",1^63;' --> 0 which makes lib.big fail because it uses ^=ord('-')^ord('+') to change sign in &bneg. I thought this was a grammar issue, except that it doesn't fail on the Vax.) I'll try the cast_neg=undef workaround, but if any of you have suggestions for what section of the code might be failing here, I'd appreciate them. MetaWare "High C" is noted for its "interesting" interpretations of the C language - it tends to do things which are legal under the ANSI C spec, but are in an "unusual" section of the undefined behavior. Though people have defended the 2.1y release, I'm prone to start with an assumption of a compiler bug (or at least "dark alley"). Further note: I took the try.c file for the cast_neg case, added the line printf("%lx,%x,%x\n",along,aint,ashort); and got 7b,7b,ff85 from it (all of these were unsigned whatever cast from double f= -123) The vax (gcc or pcc, below) gives ffffff85,ffffff85,ff85 as does gcc 1.35.99 on the RT (which isn't really trusted.) I suspect Configure is mistaken in assuming that as long as none of them are 0 it's "safe" to use this feature, but I'm not really sure how perl is (mis?)using this language feature. From my reading of the dpANS (yeah, I should get an update to the final spec): 3.2.1.2 (particularly footnote 22) indicate that the vax behavior is as specified for conversion of (for example) signed integer -123 to unsigned integer (the gist is that the two's complement representation remain the same.) However, 3.2.1.3 indicates that if the value of the integral part of a floating point value can not be represented by the integral type it is being converted to, "the behavior is undefined". This is emphasised in footnote 23, which indicates "Thus the range of portable values is [0,UtypeMAX+1)." In other words, cast_neg should probably *always* be undef, for portability, if it is truly based on the test given in Configure. os: VAX BSD 4.3 (Athena 7.2) cc: gcc -c -fpcc-struct-return -DDEBUGGING -g -O (1.37.92) ffffffff, f0000000, 81234567, ffff0000 fffffff0, f0000000, fffffffe a is 0; b is 0 (which we all agree is correct. Good old Vaxen, they're slow but they do what everyone expects...) os: Ultrix Worksystem 2.1 (version 14) [ie. Ultrix 3.1] (Athena 7.2) cc: cc2.1 -g but d_volatile='undef' 7fffffff, 7fffffff, 7fffffff, 7fffffff fffffff0, f0000000, 7fffffff a is 7; b is 0 So much for this compiler - test "cmd.for" runs forever. However, the cast_neg test above gives the same numbers as the Vax for both cc2.1 -g and gcc -g -O. (The latest gcc we have around here gets a strange assembler error on consarg.c, I'm looking for a newer version to see if that helps.) _Mark_ -- "Perl is APL on LSD. -- Seth Finkelstein "