Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!umich!samsung!usc!snorkelwacker!bloom-beacon!eru!luth!sunic!mcsun!ukc!slxsys!jclark!jjc
From: jjc@jclark.UUCP (James Clark)
Newsgroups: comp.lang.c++
Subject: cfront 2.0 bug with ANSI C compilers
Message-ID: <JJC.90Jul14150609@yquem.jclark.UUCP>
Date: 14 Jul 90 14:06:09 GMT
Sender: news@jclark.uucp
Organization: None, London, England
Lines: 43

There is an interesting bug in cfront 2.0 that arises only when
it is used with an ANSI C compiler such as gcc.

In this program

#define INT_MAX 2147483647
#define INT_MIN (-INT_MAX-1)

int foo(int n)
{
  return n >= INT_MIN;
}

#include <stdio.h>

int main()
{
  printf("foo(0) returns %d\n", foo(0));
  return 0;
}

cfront translates foo() into:

int foo__Fi(__0n)
	int __0n;
{ 
  return (__0n >= -2147483648);
}

ANSI C says that the type of 2147483648 (on a machine with 32 bit
two's complement ints) is unsigned because it's > INT_MAX.  The fact
that it's negated doesn't change this.  So the expression ends up
being evaluated using unsigned arithmetic which of course gives the
wrong answer.

This problem doesn't show up using traditional C compilers because
they give 2147483648 a signed type.

This bug can be worked around by casting INT_MIN to long.

James Clark
jjc@jclark.uucp
jjc@ai.mit.edu