On Wed, Aug 21, 2002 at 11:28:47PM -0400, Carlos O'Donell wrote: > On Wed, Aug 21, 2002 at 11:55:27AM +0300, Alexei Khlebnikov wrote: > > > I think this program should not terminate at all because i will > > > always be one greater than oldi. > > > I think gcc3.0 has a problem with no optimization then but since > > > there is later version that works gcc 3.1.1, upgrade. > > > > With no optimization the program runs correctly by the rules of integers > > representation in memory. See the explanation below. > > > > Changed my mind. After a posting from Linus on dri-devel and a discussion > about integer overflow (undefined) in C the following came out: > > --- > unsigned int i = 0; > unsigned int oldi = 0; > while ((int) ++i > (int) oldi) oldi = i; > return oldi; > --- > > Looks good... incrementing unsigned (defined overflow) and doing an > unsigned check (both operands).
Huh? No. This is not defined as far as I can see. Casting to int does not have defined meaning if the value of the unsigned int doesn't fit in int. [#3] Otherwise, the new type is signed and the value cannot be represented in it; either the result is implementation- defined or an implementation-defined signal is raised. Excuse me, it's implementation-defined. That means that GCC must choose a consistent behaviour; it is allowed to choose one such that your loop disappears, as I understand it. (int) [unsigned] may be assumed to be non-negative and thus oldi+1 > oldi. > Anyone care to jump in? :) Don't take my uneducated word for it. Ask comp.lang.c; they know these things. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer