Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!mouse
From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
Newsgroups: comp.lang.c
Subject: Re: Bug fix for Turbo C ?
Message-ID: <1991Jun29.123505.21528@thunder.mcrcim.mcgill.edu>
Date: 29 Jun 91 12:35:05 GMT
References: <1991Jun26.155139.86965@vaxc.cc.monash.edu.au>
Organization: McGill Research Centre for Intelligent Machines
Lines: 41

In article <1991Jun26.155139.86965@vaxc.cc.monash.edu.au>, apm233m@vaxc.cc.monash.edu.au writes:

> My question is: is there a patch for Turbo C++ v1.0 to fix the
> following code generation bug?
> The bug concerns the code generated for a right shift of longs.
> The following short program demonstrates the bug.

>    main() {
>    long bad=-2, good=-4;
>    printf("Is this true?: -1=%ld, -1=%ld\n", bad >> 1, good >> 2);
>    }

> My copy of TC++ generates an .exe which produces:
>    Is this true?: -1=2147483647, -1=-1

> This bug occurs only for shifts of longs, and only if the shift is by
> the constant "1".  It is a bug in the generated code; the
> preprocessor does not have the bug and therefore cannot be used to
> detect the bug.

The New Testament says, on page 206 (A7.8, Shift Operators):

	The value of E1>>E2 is E1 right-shifted E2 bit positions.  The
	right shift is equivalent to division by 2^E2 if E1 is unsigned
	or if it has a non-negative value; otherwise the result is
	implementation-defined.

Now, you say it's a C++ compiler, not a C compiler.  I don't know what,
if anything, the definition of C++ says about this.  But since you
posted to comp.lang.c instead of (! not in addition to!) comp.lang.c++,
I figure a C answer is fair game.

And from that perspective, your compiler is entirely within its rights
to do a logical shift instead of an arithmetic shift, even if it does
this only when the shift count is 1.

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu