Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Integer Overflow

Reply
Thread Tools

Integer Overflow

 
 
tm
Guest
Posts: n/a
 
      12-31-2010
On 31 Dez., 00:41, Ian Collins <(E-Mail Removed)> wrote:
> On 12/31/10 12:11 PM, tm wrote:
>
>
>
> > On 30 Dez., 23:28, Ian Collins<(E-Mail Removed)> *wrote:
> >> On 12/31/10 11:22 AM, BartC wrote:

>
> >>> With an exception, there is zero cost unless an overflow actually
> >>> occurs. If you expect these to happen all the time, then perhaps this
> >>> approach can be slower. But it is the same cost as a divide-by-zero
> >>> exception.

>
> >> But something still has perform the check.

>
> > The hardware that sets the overflow flag already performs
> > this check. It just needs to cause an interupt instead
> > or additionally to setting the flag. I don't know
> > which processors can do this, but I don't think that
> > such a feature is expensive to implement for processor
> > designers. Therefore I guess that several processors
> > already have such a possibility.

>
> So you would think, floating point errors already do.


Exactly, I just want the same technic for overflow
detection also.


Greetings Thomas Mertes

--
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
 
Reply With Quote
 
 
 
 
tm
Guest
Posts: n/a
 
      12-31-2010
On 31 Dez., 04:26, Keith Thompson <(E-Mail Removed)> wrote:
> jacob navia <(E-Mail Removed)> writes:
>
> [...]
>
> > If you write

>
> > _overflow(expression)

>
> > overflow will be checked only in the last operation of
> > "expression". Outside this construct things remain as they are
> > now.

>
> Then how is the _overflow(expression) form any better than the
> _overflow() form you had previously?


Zero cost overflow detection (no costs as long as no
overflow occurs) with interrupts is impossible when an
overflow flag needs to be checked after every expression.

I think that a proposal to do overflow detection in C
should allow zero cost overflow detection when the
hardware allows it.


Greetings Thomas Mertes

--
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      12-31-2010
jacob navia <(E-Mail Removed)> writes:
[...]
> Besides, I am scared about overflows in casts since a lot of code out
> there assumes that
>
> char c = (int) a;
>
> takes the lower 8 bits of the integer without any trap...
> At the beginning of the discussion I thought narrowing casts should
> be included but thinking it over it could be really a problem.


If plain char is unsigned, the result is well defined. If plain
char is signed, the result is implementation-defined (or an
implementation-defined signal is raised).

> The objective should be to give something practical, that does NOT
> disturb existing code.


Um, existing code doesn't invoke _overflow().

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
tm
Guest
Posts: n/a
 
      12-31-2010
On 28 Dez., 16:36, Marcin Grzegorczyk <(E-Mail Removed)> wrote:
> $ gcc -ansi -pedantic -Wall -Wextra -m32 -ftrapv test.c


I just rediscovered the -ftrapv option of gcc and started
some tests with it. I compiled my Seed7 interpreter and
found a place where I did

base = (bigdigittype) -(signedbigdigittype) base;

This line overflows when 'base' has all bits set.
The option -ftrapv causes an abort signal. I had to
change the line to

base = -base;

to avoid a signed integer overflow (base is an unsigned
value). So the - operator is used although base is an
unsigned value. Funny becaused I introduced the casts
to silent some warnings I got from a C compiler (not gcc).


Greetings Thomas Mertes

--
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
 
Reply With Quote
 
tm
Guest
Posts: n/a
 
      12-31-2010
On 31 Dez., 00:57, "Charles" <(E-Mail Removed)> wrote:
> "jacob navia" <(E-Mail Removed)> wrote in message
>
> news:ifivn6$coe$(E-Mail Removed)...
>
> > Le 30/12/10 22:26, tm a crit :
> >> I propose intoducing new types with overflow checking.
> >> The classic types int, long, ... would keep the
> >> behaviour of ignoring overflow. New types like
> >> checkd_int, checkd_long could be used for values which
> >> need overflow checking.

>
> > This is just too complicated, besides what does
> > checked_int*int ? Unchecked? checked?

>
> Ref: C++ SafeInt. It's already been done, questions already answered.
>
> http://msdn.microsoft.com/en-us/library/dd570023.aspx


Is this a protable C++ solution or a M$ only solution?


Greetings Thomas Mertes

--
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
 
Reply With Quote
 
robertwessel2@yahoo.com
Guest
Posts: n/a
 
      12-31-2010
On Dec 31, 6:22*am, tm <(E-Mail Removed)> wrote:
> On 31 Dez., 00:57, "Charles" <(E-Mail Removed)> wrote:
>
>
>
>
>
> > "jacob navia" <(E-Mail Removed)> wrote in message

>
> >news:ifivn6$coe$(E-Mail Removed)...

>
> > > Le 30/12/10 22:26, tm a crit :
> > >> I propose intoducing new types with overflow checking.
> > >> The classic types int, long, ... would keep the
> > >> behaviour of ignoring overflow. New types like
> > >> checkd_int, checkd_long could be used for values which
> > >> need overflow checking.

>
> > > This is just too complicated, besides what does
> > > checked_int*int ? Unchecked? checked?

>
> > Ref: C++ SafeInt. It's already been done, questions already answered.

>
> >http://msdn.microsoft.com/en-us/library/dd570023.aspx

>
> Is this a protable C++ solution or a M$ only solution?



It originated in MS, but is now available under their OSS-ish Ms-PL
license:

http://safeint.codeplex.com/

The documentation claims that with optimization turned on, the
overhead is about 8%, albeit under unspecified conditions (and
apparently using the MS compiler).

Interestingly, this discussion had prompted me to sketch out the
outline of something similar, and even start writing some code. This
is worth at least looking at.
 
Reply With Quote
 
Edward A. Falk
Guest
Posts: n/a
 
      01-01-2011
In article <ifcgrn$s91$(E-Mail Removed)>,
jacob navia <(E-Mail Removed)> wrote:
>
>The lcc-win compiler allows you to check for overflow in all signed
>integer operations. I have proposed that this be incorporated into
>the C language as a standard but people in comp.std.c seem to prefer
>wrong results than "wasting" some cycles in checking overflow.


I agree with them. The vast, vast majority of the time, integer
addition does not generate an overflow, and the vast, vast majority
of the cases where it does are not handled by the software. What
would you have the system do? Crash the program? Set errno, which
would almost certainly be ignored?

And how should this be implemented? Implement a hardware trap? How
many cpus even support this? Test for overflow in code after every
add or subtract?

All of these implementations and all of these handlers would be
wasting a great number of cpu cycles, all for a case which is
almost never handled anyway.

If a programmer *wants* to check for overflow, there are very
easy ways to do it in code.

C was designed to be fast, not to be bullet-proof.

--
-Ed Falk, (E-Mail Removed)
http://thespamdiaries.blogspot.com/
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      01-01-2011
(E-Mail Removed) (Edward A. Falk) writes:
> In article <ifcgrn$s91$(E-Mail Removed)>,
> jacob navia <(E-Mail Removed)> wrote:
>>The lcc-win compiler allows you to check for overflow in all signed
>>integer operations. I have proposed that this be incorporated into
>>the C language as a standard but people in comp.std.c seem to prefer
>>wrong results than "wasting" some cycles in checking overflow.

>
> I agree with them. The vast, vast majority of the time, integer
> addition does not generate an overflow, and the vast, vast majority
> of the cases where it does are not handled by the software. What
> would you have the system do? Crash the program? Set errno, which
> would almost certainly be ignored?
>
> And how should this be implemented? Implement a hardware trap? How
> many cpus even support this? Test for overflow in code after every
> add or subtract?
>
> All of these implementations and all of these handlers would be
> wasting a great number of cpu cycles, all for a case which is
> almost never handled anyway.


There is precedent for this in other languages. All your questions can,
in principle, be answered. For example, Ada requires an exception to be
raised if an arithmetic operation overflows (and allows the check to be
suppressed).

I'm not suggesting that C should become Ada, but the existence of open
questions doesn't by itself mean overflow checking shouldn't be added to
the language.

> If a programmer *wants* to check for overflow, there are very
> easy ways to do it in code.


Are there really?

I know of no *easy* way to implement the following function in
portable C:

int mul(int x, int y, int *overflow);
/* If the multiplication x * y overflows,
* returns an implementation-defined result and sets
* *overflow to 1; otherwise returns x * y and sets
* *overflow to 0.
*/

> C was designed to be fast, not to be bullet-proof.


Furthermore, if overflow checking were in the language, it would
be visible to the compiler, which could eliminate some checks if
it can prove that an overflow cannot occur.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Malcolm McLean
Guest
Posts: n/a
 
      01-02-2011
On Jan 1, 5:33*am, (E-Mail Removed) (Edward A. Falk) wrote:
>
> I agree with them. *The vast, vast majority of the time, integer
> addition does not generate an overflow, and the vast, vast majority
> of the cases where it does are not handled by the software. *What
> would you have the system do? *Crash the program? *Set errno, which
> would almost certainly be ignored?
>

Crash the program. A error message is usually better than wrong
results.


 
Reply With Quote
 
Marcin Grzegorczyk
Guest
Posts: n/a
 
      01-03-2011
tm wrote:
> I just rediscovered the -ftrapv option of gcc and started
> some tests with it. I compiled my Seed7 interpreter and
> found a place where I did
>
> base = (bigdigittype) -(signedbigdigittype) base;
>
> This line overflows when 'base' has all bits set.
> The option -ftrapv causes an abort signal. I had to
> change the line to
>
> base = -base;
>
> to avoid a signed integer overflow (base is an unsigned
> value). So the - operator is used although base is an
> unsigned value. Funny becaused I introduced the casts
> to silent some warnings I got from a C compiler (not gcc).


I think if you used just

base = (bigdigittype)-base;

it might also convince the compiler you know what you are doing. When I
did that many years ago, it worked for GCC (version 3.something, with
the -Wextra option (which was called -W back then) enabled) and
Borland's free Win32 compiler (v.5.5.1 IIRC), although in the case of
the latter it also, surprisingly, prevented the statement from being
optimized for size.
--
Marcin Grzegorczyk
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
integer or long overflow... deancoo C++ 11 03-05-2005 11:13 PM
integer overflow Ashutosh Iddya C Programming 25 04-24-2004 06:16 PM
hhow to detect overflow in integer calculation John Black C++ 1 04-15-2004 05:28 AM
unsigned integer overflow behaviour bartek C++ 3 02-06-2004 09:47 PM
Integer overflow Enrico 'Trippo' Porreca C Programming 9 08-24-2003 10:24 AM



Advertisments