🚀 go-pugleaf

gccfolk -

The attached code illustrates a gcc oddity that I can't fathom.
It's probably just an ANSI/traditional incompatibility that I
don't understand, not a gcc bug.

When compiled without -traditional, the two assignment sequences,
which appear as though they ought to be equivalent, generate different
results: The first sequence behaves as though the compiler is
treating the subexpression (i & 0x80000000) as unsigned, performing
an unsigned shift operation on it, resulting in 0x2000. The second
sequence behaves as I would (perhaps incorrectly) expect, i.e. 
a signed shift, resulting in 0xffffe000.

When compiled with -traditional, "integer overflow in expression"
warnings are generated for the i = 0x80000000 assignments (which in
itself is curious) but both expressions evaluate to 0xffffe000.

The gcc version is 2.5.5, running on a vanilla sparc IPX. Ints
and longs are 32 bits.

My Sun non-ansi C compiler evaluates both assignment sequences
identically, as 0xffffe000, and generates no warnings.

What's going on?

- Glenn Golden 				Room L-279
  Wireless Technology Research Dept.	791 Holmdel-Keyport Rd.
  AT&T Bell Laboratories		P.O. Box 400
  Voice: 908-888-7019			Holmdel, NJ 07733-0400
  Fax:   908-888-7190			email: gdg@research.att.com



----------- tear here -------------
#include	<stdio.h>

main()
{
    int		i;

    printf("sizeof(int) = %d\n", sizeof(int));

    printf("sizeof(long) = %d\n", sizeof(long));

    /*
     * First assignment sequence:
     *
     * Compiled with gcc V2.5.5, no compile-line options,
     * the following assignments result in i = 0x2000:
     */
    i = 0x80000000;
    i = (i & 0x80000000) >> 18;
    printf("this sequence results in i = 0x%x\n", i);


    /*
     * Second assignment sequence:
     *
     * This seemingly equivalent sequence of assignments
     * results in i = 0xffffe000
     */
    i = 0x80000000;
    i &= 0x80000000;
    i >>= 18;
    printf("...but this sequence results in i = 0x%x\n", i);

    exit(0);
}