Catching integer overflow

[thomas.mertes]

Is it possible to use some C or compiler extension to catch
integer overflow?

The situation is as follows:
I use C as target language for compiled Seed7 programs.
For integer computions the C type 'long' is used.
That way native C speed can be reached.

Now I want to experiment with raising a Seed7 exception
(which is emulated with setjmp(), longjmp() in C) for integer
overflow. Since the C int's and long's have undefined
behaviour on overflow, I hope to use some C or compiler
extensions to implement the overflow exceptions.

I know that a check before every integer computation
could be used to recognice an overflow, but it is not my
intention to slow down normal computations.

Normal C programs which do integer computations should
have no overhead. When an overflow happens a signal or
something else should happen that I can use to emulate
an exception.

Are there ideas to solve this problem?

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.

[Bartc]

<th***********@ gmx.atwrote in message
news:e2******** *************** ***********@d77 g2000hsb.google groups.com...

Is it possible to use some C or compiler extension to catch
integer overflow?

I know that a check before every integer computation
could be used to recognice an overflow, but it is not my
intention to slow down normal computations.

I don't think an integer overflow would typically cause a hardware
exception.

So this is down to using extra instructions, usally /after/ the operation.

This need not be a high overhead, if you were targetting x86 instead of C,
you might use 'jo label' after the add.

But C doesn't normally have this sort of thing built-in, unless it's in the
form of special compiler extensions and switches. In your case, you cannot
rely on this because your application then becomes compiler-specific (you
might as well rely on inline Asm).

There might be a few workarounds in C, but I guess they all have overheads
of some kind.

What is the purpose of this overflow check? To switch over to large integer
form? Otherwise overflow checking could be optional for the user.

--
Bartc

[thomas.mertes]

On 16 Jul., 11:51, "Bartc" <[e-mail] mwrote:

<thomas.mer...@ gmx.atwrote in message

news:e2******** *************** ***********@d77 g2000hsb.google groups.com...

Is it possible to use some C or compiler extension to catch
integer overflow?
I know that a check before every integer computation
could be used to recognice an overflow, but it is not my
intention to slow down normal computations.

I don't think an integer overflow would typically cause a hardware
exception.

Maybe it is possible to switch the hardware to a some
mode where an interrupt is raised with an integer overflow.
In that case the code for the mode switch and the
interrupt handler would be compiler/os dependend, but
the rest of the program would be plain C.

So this is down to using extra instructions, usally /after/ the operation.

This need not be a high overhead, if you were targetting x86 instead of C,
you might use 'jo label' after the add.

Is 'jo' an actual x86 instruction meaning "Jump when overflow
flag is set"?

But C doesn't normally have this sort of thing built-in, unless it's in the
form of special compiler extensions and switches. In your case, you cannot
rely on this because your application then becomes compiler-specific (you
might as well rely on inline Asm).

I know that this will probably be compiler-specific.
This is just a thing I want to explore.
What about C99 or the next C standard?

There might be a few workarounds in C, but I guess they all have overheads
of some kind.

What is the purpose of this overflow check? To switch over to large integer
form? Otherwise overflow checking could be optional for the user.

It is not my intention to switch to larger integers
on the fly. I just want to avoid undefined behaviour.

The C89 Ansi C standard states:
The handling of overflow, divide check and other exceptions
in expression evaluation is not defined by the language.
Most existing implementations of C ignore overflow in
evaluation of signed integral expressions and assignments,
but this behavior is not guaranteed.

I think that exceptions for integer overflows could
also be helpful to find bugs.

Like other range checks (for array or string access) it
could be made optional. A compiler switch or pragma could
be used to switch it on or off.

Currently I am still hoping for a zero overhead 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.

[jacob navia]

th***********@g mx.at wrote:

Is it possible to use some C or compiler extension to catch
integer overflow?

lcc-win provides the extension:

bool _overflow();

that returns the value of the overflow flag.

Obviously you should separate your operations if
you are insterested in knowing which operation overflowed.

For instance:

int a,b,c;

c = (a+b)*c;

If the overflow flag is set, it means that the multiplication
overflowed, but it is impossible to know if the addition
overflowed.

lcc-win also offers the

lcc -checkoverflow

flag when invoked. This flag will test automatically ALL operations for
overflow and abort the program if an overflow is found.

The situation is as follows:
I use C as target language for compiled Seed7 programs.
For integer computions the C type 'long' is used.
That way native C speed can be reached.

lcc-win is specially adapted for use as a back end compiler. A JIT
compiler is also available (you just pass a C code character
string instead of a file)

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Bartc]

<th***********@ gmx.atwrote in message
news:0f******** *************** ***********@s50 g2000hsb.google groups.com...

On 16 Jul., 11:51, "Bartc" <[e-mail] mwrote:

><thomas.mer... @gmx.atwrote in message

news:e2******* *************** ************@d7 7g2000hsb.googl egroups.com...

Is it possible to use some C or compiler extension to catch
integer overflow?
I know that a check before every integer computation
could be used to recognice an overflow, but it is not my
intention to slow down normal computations.

I don't think an integer overflow would typically cause a hardware
exception.

Maybe it is possible to switch the hardware to a some
mode where an interrupt is raised with an integer overflow.

I don't know. Integer overflow doesn't seem serious enough to warrant
hardware support.

>This need not be a high overhead, if you were targetting x86 instead of
C,
you might use 'jo label' after the add.

Is 'jo' an actual x86 instruction meaning "Jump when overflow
flag is set"?

Yes, in Nasm syntax anyway. For unsigned overflow a different condition
(jc?) is used. Except of course in C unsigned overflow is an impossibility.

--
Bartc

[Ben Bacarisse]

th***********@g mx.at writes:

Is it possible to use some C or compiler extension to catch
integer overflow?

<off-topic>
gcc has -ftrapv -- probably only when the target can do it
efficiently.

Presumably you don't use gcc or you'd have found it in the man page ;-)
</off-topic>

--
Ben.

[Peter Nilsson]

thomas.mer...@g mx.at wrote:

Is it possible to use some C or compiler extension to catch
integer overflow?

Have you thought about being portably proactive rather than
non-portably reactive with regards to overflow?

--
Peter

[Gordon Burditt]

>Now I want to experiment with raising a Seed7 exception

>(which is emulated with setjmp(), longjmp() in C) for integer
overflow. Since the C int's and long's have undefined
behaviour on overflow, I hope to use some C or compiler
extensions to implement the overflow exceptions.

I know that a check before every integer computation
could be used to recognice an overflow, but it is not my
intention to slow down normal computations.

Normal C programs which do integer computations should
have no overhead. When an overflow happens a signal or
something else should happen that I can use to emulate
an exception.

I don't think your goal of *NO* overhead is possible, even in most
assembly languages (and in particular, not on x86). It may be
possible with floating point, as you can enable exceptions to cause
traps. Some of this is even controllable in C by IEEE floating-point
extensions. (Although I am *not* sure that enabling exceptions
doesn't slow down the instruction a bit even when there isn't an
exception taken) But not with integer calculations.

On x86, you can't use instructions like branch-on-overflow or
trap-on-overflow because they are instructions and cause overhead.
You demanded no overhead.

*IF* you could get the compiler to place a trap-on-overflow
instruction after each signed integer calculation (but not on
the unsigned integer calculations), and you catch whatever
signal the trap-on-overflow instruction generates, that's
probably the best you can get. You'll still have overhead.

[Keith Thompson]

"Bartc" <[e-mail] rites:
[...]

I don't know. Integer overflow doesn't seem serious enough to warrant
hardware support.

[...]

You'd rather have wrong answers quickly?

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <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"

[Bartc]

"Gordon Burditt" <go***********@ burditt.orgwrot e in message
news:D5******** *************** *******@posted. internetamerica ...

Now I want to experiment with raising a Seed7 exception
(which is emulated with setjmp(), longjmp() in C) for integer
overflow.

>>Normal C programs which do integer computations should
have no overhead.

On x86, you can't use instructions like branch-on-overflow or
trap-on-overflow because they are instructions and cause overhead.
You demanded no overhead.

*IF* you could get the compiler to place a trap-on-overflow
instruction after each signed integer calculation (but not on
the unsigned integer calculations),

This is for implementing a different language, which could well have the
concept of unsigned overflow:

If my unsigned int can only store 0..9, I may want to know that 5+7 only
gave me 2 instead of the correct 12.

--
Bartc