clewis@ecicrl.UUCP (Chris Lewis) (12/03/90)
Complement of 0 doesn't work as expected (Perl 3, PL41, AT&T 3b1, 3.5.1.4).
The following perl program:
$foo = 0;
printf "%o, %x, %o\n", 0666, ~$foo, 0666 & ~$foo;
prints:
666, 80000000, 0
Complement of 0 should be 0xFFFFFFFF (-1) not 0x80000000.
This is newish behaviour - worked fine at PL 27. My umask emulator
now makes all the files mode 000. Yuck.
--
Chris Lewis, Phone: (613) 832-0541
UUCP: uunet!utai!lsuc!ecicrl!clewis
Moderator of the Ferret Mailing List (ferret-request@eci386)
Psroff mailing list (psroff-request@eci386)gorpong@ping.uucp (Gordon C. Galligher) (12/04/90)
In article <978@ecicrl.UUCP> clewis@ecicrl.UUCP (Chris Lewis) writes: >Complement of 0 doesn't work as expected (Perl 3, PL41, AT&T 3b1, 3.5.1.4). ^^^^^^^^^^^^^^^^^ My guess is the system, or the way you compiled it. On a Sun3 running SunOS 4.1 it works like you would expect (666, ffffff, 666). It also works like you expect on an 80386 running SCO "unix" V3.2.2. (These are all Perl 3.0PL41.) This is just my mileage. -- Gordon. -- Gordon C. Galligher 9127 Potter Rd. #2E Des Plaines, IL 60016-4881 ...!{uupsi,uu.psi.com}!ping!gorpong
jmc@teqsoft.UUCP (Jack Cloninger) (12/04/90)
clewis@ecicrl.UUCP (Chris Lewis) writes: >Complement of 0 doesn't work as expected (Perl 3, PL41, AT&T 3b1, 3.5.1.4). >The following perl program: > $foo = 0; > printf "%o, %x, %o\n", 0666, ~$foo, 0666 & ~$foo; >prints: > 666, 80000000, 0 >Complement of 0 should be 0xFFFFFFFF (-1) not 0x80000000. Chris, I get: 666, ffffffff, 666 Running Perl 3, PL41, MLC 386SX, SCO UNIX 3.2 v 2.0. Jack -- Jack Cloninger, TeqSoft, 112 US Highway 1, Tequesta, FL 33469 B-) ...uunet!comtst!teqsoft!jmc Phone: 407-747-7163 Fax: 407-747-0354
clewis@ecicrl.UUCP (Chris Lewis) (12/06/90)
In article <978@ecicrl.UUCP> clewis@ecicrl.UUCP (Chris Lewis) writes: >Complement of 0 doesn't work as expected (Perl 3, PL41, AT&T 3b1, 3.5.1.4). > $foo = 0; > printf "%o, %x, %o\n", 0666, ~$foo, 0666 & ~$foo; >prints: > 666, 80000000, 0 Sigh. Problem found. 3b1 C compiler has a bug in it regarding complement and unsigned long. Vis, the following code: main() { double f; long l; l = (unsigned long) 0.0; f = (double) ~l; printf("%x %f\n", l, f); /* similar to eval.c code expression under O_COMPLEMENT */ f = (double) ~(unsigned long) 0.0; printf("%f %x\n", f, (unsigned long) f); } Which produces: 0 -1.000000 4294967295.000000 80000000 H'm, the first line is correct, and the second is not. I've checked this also with unary negate, but this doesn't happen. (yeah, I know this doesn't pass lint... but on a 68010 that wouldn't cause a problem) Even more interesting, when I turn the "long l" into "unsigned long l", it buggers up again. I'm going to get around this by introducing a signed long variable ala l. (I don't want to fool around with the U_L() stuff). Other 3b1 owners may want to check their compilers if they aren't 3.5.1.4, and 3b1 "support" (if such still exists) may want to take note of this bug. 3b1 gcc appears to not have this problem. -- Chris Lewis, Phone: (613) 832-0541 UUCP: uunet!utai!lsuc!ecicrl!clewis Moderator of the Ferret Mailing List (ferret-request@eci386) Psroff mailing list (psroff-request@eci386)