Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uwm.edu!rpi!brutus.cs.uiuc.edu!apple!motcsd!motsj1!mcdchg!att!cbnewsd!knudsen
From: knudsen@cbnewsd.ATT.COM (michael.j.knudsen)
Newsgroups: comp.lang.c
Subject: Re: is this broken or what?
Summary: is unsigned (i >= 0) always true?
Message-ID: <12981@cbnewsd.ATT.COM>
Date: 31 Jan 90 18:47:19 GMT
References: <2033@crdos1.crd.ge.COM> <572@idacrd.UUCP> <28941@amdcad.AMD.COM> <15793@haddock.ima.isc.com>
Organization: AT&T Bell Laboratories
Lines: 28

One of my "favorite" bugs is
	unsigned	i;
	...
	while(i >= 0) {......}

You can wait a long time for this to terminate....

My question is whether (i >= 0) is ALWAYS TRUE for unsigned i
in all dialects of C (including ANSI) and all hardware architectures,
or am I missing something?

I ask this partly because apparently ANSI has defined "overflow"
to require "change in sign", thus they can say with a straight face
that "unsigned ints never overflow".  I'd like to see their faces
when they try telling that to the hardware (remember that?)
that generates interrupts on overflow.
Seriously, unsigned declarations just control how the compiler
chooses conditional branch instructions when compiling |>| etc.
("higher" versus "greater"), so it's too late to call off
hardware overflow interrupts after a subtraction.

Or does ANSI require that such interrupts be disabled before
executing unsigned comparisons, and re-enabled beofre the next signed
one?
-- 
Mike Knudsen  knudsen@ihlpl.att.com   (708)-713-5134
"Round and round the while() loop goes;
        Whether it stops," Turing says, "no one knows."