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: <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