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.

- Raw text -