Path: utzoo!attcan!uunet!dino!ux1.cso.uiuc.edu!uwm.edu!dogie.macc.wisc.edu!vms.macc.wisc.edu From: yahnke@vms.macc.wisc.edu (Ross Yahnke, MACC) Newsgroups: comp.sys.mac.programmer Subject: Re: THINK C bug Message-ID: <3137@dogie.macc.wisc.edu> Date: 7 Feb 90 15:23:34 GMT Sender: news@dogie.macc.wisc.edu Organization: University of Wisconsin Academic Computing Center Lines: 24 In article <6661@ucdavis.ucdavis.edu>, lim@iris.ucdavis.edu (Lloyd Lim) writes... -I'm using THINK C 4.0 and it won't accept the constant -2147483648 but it -does accept -2147483647 and 2147483647. This value does fit in a long. -Curiously, it does accept 0x80000000 and -2147483647 - 1. Looks suspicious to me. Defining the constant -2147483647 and assigning it to a long results in the assembly instruction: MOVE.L #$80000001, ... But as you say, the compiler rejects the constant -2147483648. I wonder though if the Think C folks are aware of this, cuz in their "limits.h" header they've defined a constant LONG_MIN which in the documentation is defined to be -2147483648 but in the actual header file is defined as: #define LONG_MIN (~2147483647) which results in the assembly instruction: MOVE.L #$80000000, ... Probably one of those pesky loose ends that M. Kahl never got to clearing up.... >>> Internet: yahnke@macc.wisc.edu <<< >>> Mille voix chuchottent <> <<<