is this broken or what?
Michael Meissner
meissner at osf.org
Sat Feb 3 01:34:46 AEST 1990
In article <12981 at cbnewsd.ATT.COM>, knudsen at cbnewsd.ATT.COM
(michael.j.knudsen) writes:
| 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?
The ANSI standard requires that unsigned arithmetic be done modulus
2**n (where n is the wordsize of the unsigned int or long). This
specifically means on machines that insist on interrupting on
overflow, that either the compiler generates code to turn off such
interrupts before each unsigned operation; or fix the exception
handler to recognize such cases, and do the right thing (by continuing
the program).
For example, the Data General MV/Eclipse machine had a bit in the PSW
saying whether or not integer overflow interrupts would be generated,
and the function prologue would set the bit appropriately. There were
also instructions to turn on and off the interrupts for the function.
By default, the C compiler always turned off these interrupts, but it
had an option to enable interrupts. If the option was used, before
each unsigned instruction, the compiler would then turn off
interrupts, do the instruction, and turn them back on.....
--
Michael Meissner email: meissner at osf.org phone: 617-621-8861
Open Software Foundation, 11 Cambridge Center, Cambridge, MA
Catproof is an oxymoron, Childproof is nearly so
More information about the Comp.lang.c
mailing list