|[12 earlier articles]|
|Re: Integers on 64-bit machines DrDiettrich1@aol.com (Hans-Peter Diettrich) (2007-07-06)|
|Re: Integers on 64-bit machines email@example.com (2007-07-06)|
|Re: Integers on 64-bit machines firstname.lastname@example.org (Marco van de Voort) (2007-07-08)|
|Re: Integers on 64-bit machines cfc@shell01.TheWorld.com (Chris F Clark) (2007-07-08)|
|Re: Integers on 64-bit machines DrDiettrich1@aol.com (Hans-Peter Diettrich) (2007-07-09)|
|Re: Integers on 64-bit machines email@example.com (2007-07-09)|
|Re: Integers on 64-bit machines firstname.lastname@example.org (George Neuner) (2007-07-09)|
|Re: Integers on 64-bit machines email@example.com (Tony Finch) (2007-07-09)|
|Re: Integers on 64-bit machines firstname.lastname@example.org (Marco van de Voort) (2007-07-10)|
|Re: Integers on 64-bit machines DrDiettrich1@aol.com (Hans-Peter Diettrich) (2007-07-13)|
|Re: Integers on 64-bit machines cfc@shell01.TheWorld.com (Chris F Clark) (2007-07-13)|
|Re: Integers on 64-bit machines email@example.com (napi) (2007-07-13)|
|Re: Integers on 64-bit machines firstname.lastname@example.org (Stefan Monnier) (2007-07-14)|
|[3 later articles]|
|From:||George Neuner <email@example.com>|
|Date:||Mon, 09 Jul 2007 06:28:16 -0400|
|References:||07-07-007 07-07-014 07-07-017 07-07-026|
|Keywords:||arithmetic, storage, design|
On Fri, 06 Jul 2007 06:22:49 +0200, Hans-Peter Diettrich
>Consider a common situation: the difference between two n-bit values
>requires n+1 bits, or overflows can occur when less bits are used for
>the result. Using an subrange type of wordsize-n bits, both the user and
>the compiler can be sure that a sum or difference cannot produce an
>overflow, in computations with full wordsize registers or variables.
>A common situation, found in many open source C codes, are comparisons
>of signed and unsigned values. The Delphi compiler warns the user, that
>the comparison requires to extend the values to the next higher type. I
>dunno what a C compiler will do in such cases, but in Delphi I can use
>appropriate subrange types to eliminate such conversions.
Subranges are mapped into an appropriately sized integral type. So
depending on where you make your range declaration(s), you are either
using a larger data type everywhere or performing a local conversion
Actually, the integer compare instructions on many CPUs correctly
handles the n+1 bit result, but a compiler may choose instead to use
subtraction and not catch the over/underflow.
Most C compilers warn about mixing signed and unsigned values in an
expression - at least if the programmer doesn't turn off the warning.
Comparing them is usually a stupid mistake, but it works except at the
corner case where the unsigned value exceeds the largest positive
value of the corresponding signed type. C doesn't catch integer
over/underflows and it won't warn you about the possibility.
>Now tell me please, how one can prevent overflows or inappropriate or
>bloated comparison code, when e.g. only a single integer type is available.
You either have to catch the overflow (possibly using assembler) or
change the data representation - e.g., by scaling or offsetting - to
make sure an overflow can't happen.
If the data cooperates, one trick you can use in C is to define
reduced range integer types using structures and bit fields. For
example, if you define a 20-bit signed type and a 19-bit unsigned
type, you know that these can be compared cleanly (even if the
compiler warns) and that an unsigned value could be safely assigned to
a signed type (though not the reverse).
Bit field integers must fit into a machine register (so no 37-bit
integers on a 32-bit machine :) and they require masking or shifting
so they are slower to use than plain integers (though the hit is
generally minor if you limit one bit field to a structure). And the
compiler still won't warn you if you screw up using them - they obey
the same rules as normal C integers. But with an appropriate variable
naming scheme you could at least look at an expression and be able to
tell whether it might bust.
for email reply remove "/" from address
Return to the
Search the comp.compilers archives again.