From:	eplmst AT lu DOT erisoft DOT se (Martin Stromberg)
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: Lack of overflow problem
Date:	11 Jan 2000 09:29:12 GMT
Organization:	Ericsson Erisoft AB, Sweden
Lines:	22
Message-ID:	<85et58$5to$1@antares.lu.erisoft.se>
References:	<dhwa4.274$Gh2 DOT 1735 AT newsfeed DOT slurp DOT net> <851dtd$bfv$1 AT news DOT luth DOT se> <854cnj$453 AT romeo DOT logica DOT co DOT uk> <854fv0$a7bo$1 AT newssvr03-int DOT news DOT prodigy DOT com> <856fl6$bg24$1 AT newssvr03-int DOT news DOT prodigy DOT com>
NNTP-Posting-Host:	spica-144.lu.erisoft.se
X-Newsreader:	TIN [version 1.2 PL2]
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp
Reply-To:	djgpp AT delorie DOT com

Michael Farnham (MCFARNHAM AT prodigy DOT net) wrote:
: I have done some code testing and have come to some conclusions.
:     * With no optimizations turned on and when s is an int the loop
:       quits when s = INT_MAX (from limits.h or climits).
:     * When s is a char s + 1 is implicitly converted to int and the
:       loop is infinite.
:     * If s is a type where the maximum value is less than INT_MAX
:       (e.g. CHAR_MAX < INT_MAX), then s + 1 will be converted to an
:       int and the loop will be infinite. If s is an int then the
:       loop will terminate when s = INT_MAX.
:     * If the only purpose of this loop is to identify the maximum
:       value for the type then it would be easier to use the value
:       defined in the standard header file limits.h (C) or climits (C++).


How about giving gcc the -S option and look at the resulting assembly
code to figure out how gcc compiles it?


This Mortal Coil, Blood,

							MartinS

- Raw text -