Xref: news2.mv.net comp.os.msdos.djgpp:3007
From: mcantos AT ocean DOT com DOT au (Marcelo Cantos)
Newsgroups: comp.os.msdos.djgpp
Subject: Re: LONG_MIN question
Date: Tue, 23 Apr 96 01:44:19 GMT
Organization: (private)
Lines: 19
Message-ID: <4lhg62$mj8@news.mel.aone.net.au>
References: <199604201839 DOT LAA28457 AT netcom5 DOT netcom DOT com>
NNTP-Posting-Host: 203.12.234.179
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

>>   2-Why this problem exists? Why doing (-2147483647L-1L) does not produce
>>     the same problem?

the string "-2147483648L" is interpreted by the compiler's lexical analyser as 
two tokens: a negation operator ("-") and a number ("2147483648L") this causes 
an overflow in the parsing stage because 2147483648 is not a long. The problem 
is solved with the definition used in limits.h.


>>   3-Why DJGPP defines
>>       #define SHRT_MIN (-32768)
>>     and BC++4.52 defines
>>       #define SHRT_MIN (-32767-1)
>>     even for 32 bit applications?

Perhaps BC considers -32768 an int because it is actually an expression: "-" 
"32768". Once again, 32768 is not a short, but an int. I suspect it really 
doesn't matter, and that Borland used its definition solely for consistency 
with the other definitions.