Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #5905 > unrolled thread
| Started by | rop rop <rop049@gmail.com> |
|---|---|
| First post | 2011-07-06 08:35 -0700 |
| Last post | 2011-07-09 12:16 -0700 |
| Articles | 20 on this page of 277 — 46 participants |
Back to article view | Back to comp.lang.java.programmer
Arithmetic overflow checking rop rop <rop049@gmail.com> - 2011-07-06 08:35 -0700
Re: Arithmetic overflow checking markspace <-@.> - 2011-07-06 09:42 -0700
Re: Arithmetic overflow checking stefan@nyniva.se - 2011-07-06 11:30 -0700
Re: Arithmetic overflow checking markspace <-@.> - 2011-07-06 11:36 -0700
Re: Arithmetic overflow checking Arne Vajhøj <arne@vajhoej.dk> - 2011-07-18 23:06 -0400
Re: Arithmetic overflow checking Patricia Shanahan <pats@acm.org> - 2011-07-06 10:16 -0700
Re: Arithmetic overflow checking "John B. Matthews" <nospam@nospam.invalid> - 2011-07-07 02:26 -0400
Re: Arithmetic overflow checking Arne Vajhøj <arne@vajhoej.dk> - 2011-07-18 23:07 -0400
Re: Arithmetic overflow checking Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2011-07-07 07:11 -0700
Re: Arithmetic overflow checking Patricia Shanahan <pats@acm.org> - 2011-07-07 10:02 -0700
Re: Arithmetic overflow checking Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2011-07-07 17:51 -0700
Re: Arithmetic overflow checking Patricia Shanahan <pats@acm.org> - 2011-07-07 20:04 -0700
Re: Arithmetic overflow checking Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2011-07-07 20:29 -0700
Re: Arithmetic overflow checking rop rop <rop049@gmail.com> - 2011-07-08 15:52 -0700
Re: Arithmetic overflow checking Arne Vajhøj <arne@vajhoej.dk> - 2011-07-18 23:12 -0400
Re: Arithmetic overflow checking Tom Anderson <twic@urchin.earth.li> - 2011-07-09 10:31 +0100
Re: Arithmetic overflow checking rop rop <rop049@gmail.com> - 2011-07-09 02:58 -0700
Re: Arithmetic overflow checking Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-07-09 08:53 -0400
Re: Arithmetic overflow checking markspace <-@.> - 2011-07-09 07:46 -0700
Re: Arithmetic overflow checking Arne Vajhøj <arne@vajhoej.dk> - 2011-07-18 23:17 -0400
Re: Arithmetic overflow checking Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2011-07-18 23:22 -0700
Re: Arithmetic overflow checking tm <thomas.mertes@gmx.at> - 2011-07-10 01:47 -0700
Re: Arithmetic overflow checking China Blue Dolls <chine.bleu@yahoo.com> - 2011-07-10 02:47 -0700
Re: Arithmetic overflow checking pete <pfiland@mindspring.com> - 2011-07-10 06:04 -0400
Re: Arithmetic overflow checking China Blue Dolls <chine.bleu@yahoo.com> - 2011-07-10 03:29 -0700
Re: Arithmetic overflow checking Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-07-10 20:52 +0300
Re: Arithmetic overflow checking pete <pfiland@mindspring.com> - 2011-07-10 23:29 -0400
Re: Arithmetic overflow checking tm <thomas.mertes@gmx.at> - 2011-07-10 04:44 -0700
Re: Arithmetic overflow checking "BartC" <bc@freeuk.com> - 2011-07-12 11:33 +0100
Re: Arithmetic overflow checking tm <thomas.mertes@gmx.at> - 2011-07-12 04:17 -0700
Re: Arithmetic overflow checking "BartC" <bc@freeuk.com> - 2011-07-12 12:33 +0100
Re: Arithmetic overflow checking tm <thomas.mertes@gmx.at> - 2011-07-12 05:24 -0700
Re: Arithmetic overflow checking Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-07-12 21:45 -0400
Re: Arithmetic overflow checking Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-07-12 05:25 -0700
Re: Arithmetic overflow checking tm <thomas.mertes@gmx.at> - 2011-07-12 10:21 -0700
Re: Arithmetic overflow checking tm <thomas.mertes@gmx.at> - 2011-07-12 23:54 -0700
Re: Arithmetic overflow checking "BartC" <bc@freeuk.com> - 2011-07-12 19:14 +0100
Re: Arithmetic overflow checking Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-07-13 00:20 -0700
Re: Arithmetic overflow checking markspace <-@.> - 2011-07-12 09:26 -0700
Re: Arithmetic overflow checking Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-07-12 10:52 -0600
Re: Arithmetic overflow checking Keith Thompson <kst-u@mib.org> - 2011-07-12 10:48 -0700
Re: Arithmetic overflow checking Martin Gregorie <martin@address-in-sig.invalid> - 2011-07-12 16:54 +0000
Re: Arithmetic overflow checking Gene Wirchenko <genew@ocis.net> - 2011-07-12 11:35 -0700
Re: Arithmetic overflow checking tm <thomas.mertes@gmx.at> - 2011-07-12 10:13 -0700
Re: Arithmetic overflow checking Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-07-12 21:53 -0400
Re: Arithmetic overflow checking "MikeP" <mp011011@some.org> - 2011-07-14 23:41 -0500
Re: Arithmetic overflow checking Gene Wirchenko <genew@ocis.net> - 2011-07-15 10:56 -0700
Re: Arithmetic overflow checking "MikeP" <mp011011@some.org> - 2011-07-15 21:27 -0500
Re: Arithmetic overflow checking bugbear <bugbear@trim_papermule.co.uk_trim> - 2011-07-20 09:22 +0100
Re: Arithmetic overflow checking tm <thomas.mertes@gmx.at> - 2011-07-20 10:51 -0700
Re: Arithmetic overflow checking gordonb.3urm7@burditt.org (Gordon Burditt) - 2011-07-20 15:39 -0500
Re: Arithmetic overflow checking "BartC" <bc@freeuk.com> - 2011-07-21 12:12 +0100
Re: Arithmetic overflow checking Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-07-10 09:28 -0400
Re: Arithmetic overflow checking Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-07-10 06:52 -0700
Re: Arithmetic overflow checking Keith Thompson <kst-u@mib.org> - 2011-07-10 14:47 -0700
Re: Arithmetic overflow checking "MikeP" <mp011011@some.org> - 2011-07-14 23:07 -0500
Re: Arithmetic overflow checking Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-07-10 12:25 -0400
Re: Arithmetic overflow checking Robert Wessel <robertwessel2@yahoo.com> - 2011-07-10 10:47 -0500
Re: Arithmetic overflow checking Gene Wirchenko <genew@ocis.net> - 2011-07-11 07:58 -0700
Re: Arithmetic overflow checking Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-07-11 10:48 -0700
Re: Arithmetic overflow checking Gene Wirchenko <genew@ocis.net> - 2011-07-11 14:40 -0700
Re: Arithmetic overflow checking tm <thomas.mertes@gmx.at> - 2011-07-11 14:54 -0700
Re: Arithmetic overflow checking Gene Wirchenko <genew@ocis.net> - 2011-07-11 15:55 -0700
Re: Arithmetic overflow checking Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-07-11 21:51 -0400
Re: Arithmetic overflow checking Gene Wirchenko <genew@ocis.net> - 2011-07-11 21:31 -0700
Re: Arithmetic overflow checking Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-07-11 23:16 -0700
Re: Arithmetic overflow checking James Kuyper <jameskuyper@verizon.net> - 2011-07-12 06:28 -0400
Re: Arithmetic overflow checking David Thompson <dave.thompson2@verizon.net> - 2011-07-24 22:13 -0400
Re: Arithmetic overflow checking Lew Pitcher <lpitcher@teksavvy.com> - 2011-07-25 10:24 -0400
Re: Arithmetic overflow checking "io_x" <a@b.c.invalid> - 2011-07-12 09:05 +0200
Re: Arithmetic overflow checking tm <thomas.mertes@gmx.at> - 2011-07-12 02:22 -0700
Re: Arithmetic overflow checking "io_x" <a@b.c.invalid> - 2011-07-12 11:34 +0200
Re: Arithmetic overflow checking Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-07-12 03:04 -0700
Re: Arithmetic overflow checking tm <thomas.mertes@gmx.at> - 2011-07-12 03:33 -0700
Re: Arithmetic overflow checking David Lamb <dalamb@cs.queensu.ca> - 2011-07-12 08:29 -0400
Re: Arithmetic overflow checking "io_x" <a@b.c.invalid> - 2011-07-12 13:18 +0200
Re: Arithmetic overflow checking Gene Wirchenko <genew@ocis.net> - 2011-07-12 11:39 -0700
Re: Arithmetic overflow checking Patricia Shanahan <pats@acm.org> - 2011-07-12 12:38 -0700
Re: Arithmetic overflow checking markspace <-@.> - 2011-07-12 13:20 -0700
Re: Arithmetic overflow checking Gene Wirchenko <genew@ocis.net> - 2011-07-12 13:23 -0700
Re: Arithmetic overflow checking Martin Gregorie <martin@address-in-sig.invalid> - 2011-07-12 21:08 +0000
Re: Arithmetic overflow checking lewbloch <lewbloch@gmail.com> - 2011-07-12 14:48 -0700
Re: Arithmetic overflow checking Gene Wirchenko <genew@ocis.net> - 2011-07-12 15:24 -0700
Re: Arithmetic overflow checking lewbloch <lewbloch@gmail.com> - 2011-07-12 16:09 -0700
Re: Arithmetic overflow checking Gene Wirchenko <genew@ocis.net> - 2011-07-13 10:38 -0700
Re: Arithmetic overflow checking Patricia Shanahan <pats@acm.org> - 2011-07-13 11:00 -0700
Re: Arithmetic overflow checking lewbloch <lewbloch@gmail.com> - 2011-07-13 12:16 -0700
Re: Arithmetic overflow checking Gene Wirchenko <genew@ocis.net> - 2011-07-13 13:10 -0700
Re: Arithmetic overflow checking markspace <-@.> - 2011-07-13 13:21 -0700
Re: Arithmetic overflow checking Keith Thompson <kst-u@mib.org> - 2011-07-13 13:41 -0700
Re: Arithmetic overflow checking Robert Wessel <robertwessel2@yahoo.com> - 2011-07-14 21:10 -0500
Re: Arithmetic overflow checking "io_x" <a@b.c.invalid> - 2011-07-15 11:57 +0200
Re: Arithmetic overflow checking Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-07-15 04:36 -0700
Re: Arithmetic overflow checking Niklas Holsti <niklas.holsti@tidorum.invalid> - 2011-08-13 21:54 +0300
Re: Arithmetic overflow checking tm <thomas.mertes@gmx.at> - 2011-07-13 00:52 -0700
Re: Arithmetic overflow checking Patricia Shanahan <pats@acm.org> - 2011-07-13 07:45 -0700
Re: Arithmetic overflow checking Wolfgang Draxinger <wdraxinger@darkstargames.de> - 2011-09-08 21:02 +0200
Re: Arithmetic overflow checking Wolfgang Draxinger <wdraxinger@darkstargames.de> - 2011-09-08 21:12 +0200
Re: Arithmetic overflow checking Willem <willem@toad.stack.nl> - 2011-09-08 19:15 +0000
Re: Arithmetic overflow checking Wolfgang Draxinger <wdraxinger@darkstargames.de> - 2011-09-08 22:24 +0200
Re: Arithmetic overflow checking Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-07-08 00:30 -0400
Re: Arithmetic overflow checking Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2011-07-08 01:29 -0700
Re: Arithmetic overflow checking markspace <-@.> - 2011-07-08 07:38 -0700
Re: Arithmetic overflow checking Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-07-08 20:40 -0400
Re: Arithmetic overflow checking markspace <-@.> - 2011-07-08 18:17 -0700
Re: Arithmetic overflow checking Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2011-07-08 19:49 -0700
Re: Arithmetic overflow checking markspace <-@.> - 2011-07-08 22:26 -0700
Re: Arithmetic overflow checking Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2011-07-08 17:42 -0700
Re: Arithmetic overflow checking Tom Anderson <twic@urchin.earth.li> - 2011-07-09 10:21 +0100
Re: Arithmetic overflow checking David Lamb <dalamb@cs.queensu.ca> - 2011-07-10 10:53 -0400
Re: Arithmetic overflow checking Martin Gregorie <martin@address-in-sig.invalid> - 2011-07-10 18:07 +0000
Re: Arithmetic overflow checking Patricia Shanahan <pats@acm.org> - 2011-07-10 11:29 -0700
Re: Arithmetic overflow checking Martin Gregorie <martin@address-in-sig.invalid> - 2011-07-10 19:22 +0000
Re: Arithmetic overflow checking Arne Vajhøj <arne@vajhoej.dk> - 2011-07-21 16:40 -0400
Re: Arithmetic overflow checking Martin Gregorie <martin@address-in-sig.invalid> - 2011-07-21 23:06 +0000
Re: Arithmetic overflow checking Arne Vajhøj <arne@vajhoej.dk> - 2011-07-21 19:38 -0400
Re: Arithmetic overflow checking Henderson <h1@g1.f1> - 2011-07-22 00:27 -0400
Re: Arithmetic overflow checking Martin Gregorie <martin@address-in-sig.invalid> - 2011-07-22 13:00 +0000
Re: Arithmetic overflow checking markspace <-@.> - 2011-07-10 17:17 -0700
Re: Arithmetic overflow checking Gene Wirchenko <genew@ocis.net> - 2011-07-08 10:23 -0700
Re: Arithmetic overflow checking "John B. Matthews" <nospam@nospam.invalid> - 2011-07-08 19:30 -0400
Re: Arithmetic overflow checking Gene Wirchenko <genew@ocis.net> - 2011-07-11 08:04 -0700
Re: Arithmetic overflow checking Arne Vajhøj <arne@vajhoej.dk> - 2011-07-21 16:43 -0400
Re: Arithmetic overflow checking "MikeP" <mp011011@some.org> - 2011-07-15 00:28 -0500
Re: Arithmetic overflow checking Arne Vajhøj <arne@vajhoej.dk> - 2011-07-18 23:09 -0400
Re: Arithmetic overflow checking "MikeP" <mp011011@some.org> - 2011-07-15 00:14 -0500
Re: Arithmetic overflow checking Patricia Shanahan <pats@acm.org> - 2011-07-15 07:00 -0700
Re: Arithmetic overflow checking lewbloch <lewbloch@gmail.com> - 2011-07-15 08:09 -0700
Re: Arithmetic overflow checking Arne Vajhøj <arne@vajhoej.dk> - 2011-07-20 22:07 -0400
Re: Arithmetic overflow checking "MikeP" <mp011011@some.org> - 2011-07-15 23:29 -0500
Re: Arithmetic overflow checking Patricia Shanahan <pats@acm.org> - 2011-07-15 22:26 -0700
Re: Arithmetic overflow checking "MikeP" <mp011011@some.org> - 2011-07-16 00:32 -0500
Re: Arithmetic overflow checking lewbloch <lewbloch@gmail.com> - 2011-07-16 11:00 -0700
Re: Arithmetic overflow checking Patricia Shanahan <pats@acm.org> - 2011-07-16 11:15 -0700
Re: Arithmetic overflow checking "MikeP" <mp011011@some.org> - 2011-07-16 15:41 -0500
Re: Arithmetic overflow checking Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-07-16 23:18 +0000
Re: Arithmetic overflow checking "MikeP" <mp011011@some.org> - 2011-07-17 00:30 -0500
Re: Arithmetic overflow checking "John B. Matthews" <nospam@nospam.invalid> - 2011-07-16 08:39 -0400
Re: Arithmetic overflow checking lewbloch <lewbloch@gmail.com> - 2011-07-16 10:33 -0700
Re: Arithmetic overflow checking "MikeP" <mp011011@some.org> - 2011-07-16 15:51 -0500
Re: Arithmetic overflow checking lewbloch <lewbloch@gmail.com> - 2011-07-17 08:46 -0700
Re: Arithmetic overflow checking "MikeP" <mp011011@some.org> - 2011-07-18 07:03 -0500
Re: Arithmetic overflow checking lewbloch <lewbloch@gmail.com> - 2011-07-18 06:21 -0700
Re: Arithmetic overflow checking "MikeP" <mp011011@some.org> - 2011-07-16 15:43 -0500
Re: Arithmetic overflow checking "John B. Matthews" <nospam@nospam.invalid> - 2011-07-17 09:50 -0400
Re: Arithmetic overflow checking Patricia Shanahan <pats@acm.org> - 2011-07-17 08:15 -0700
Re: Arithmetic overflow checking "John B. Matthews" <nospam@nospam.invalid> - 2011-07-18 01:12 -0400
Re: Arithmetic overflow checking Arne Vajhøj <arne@vajhoej.dk> - 2011-07-21 16:50 -0400
Re: Arithmetic overflow checking "MikeP" <mp011011@some.org> - 2011-07-18 06:56 -0500
Re: Arithmetic overflow checking David Lamb <dalamb@cs.queensu.ca> - 2011-07-18 19:26 -0400
Re: Arithmetic overflow checking Gene Wirchenko <genew@ocis.net> - 2011-07-18 15:03 -0700
Re: Arithmetic overflow checking Arne Vajhøj <arne@vajhoej.dk> - 2011-07-20 22:16 -0400
Re: Arithmetic overflow checking Henderson <h1@g1.f1> - 2011-07-20 22:25 -0400
Re: Arithmetic overflow checking David Lamb <dalamb@cs.queensu.ca> - 2011-07-21 08:50 -0400
Re: Arithmetic overflow checking lewbloch <lewbloch@gmail.com> - 2011-07-21 07:37 -0700
Re: Arithmetic overflow checking Arne Vajhøj <arne@vajhoej.dk> - 2011-07-21 16:52 -0400
Re: Arithmetic overflow checking Martin Gregorie <martin@address-in-sig.invalid> - 2011-07-21 12:19 +0000
Re: Arithmetic overflow checking Arne Vajhøj <arne@vajhoej.dk> - 2011-07-21 16:54 -0400
Re: Arithmetic overflow checking Gene Wirchenko <genew@ocis.net> - 2011-07-21 14:46 -0700
Re: Arithmetic overflow checking Arne Vajhøj <arne@vajhoej.dk> - 2011-07-21 18:10 -0400
Re: Arithmetic overflow checking Martin Gregorie <martin@address-in-sig.invalid> - 2011-07-21 23:22 +0000
Re: Arithmetic overflow checking "John B. Matthews" <nospam@nospam.invalid> - 2011-07-21 21:47 -0400
Re: Arithmetic overflow checking David Lamb <dalamb@cs.queensu.ca> - 2011-07-23 10:15 -0400
Re: Arithmetic overflow checking lewbloch <lewbloch@gmail.com> - 2011-07-16 10:46 -0700
Re: Arithmetic overflow checking Patricia Shanahan <pats@acm.org> - 2011-07-16 11:13 -0700
Re: Arithmetic overflow checking Arne Vajhøj <arne@vajhoej.dk> - 2011-07-20 22:09 -0400
Re: Arithmetic overflow checking lewbloch <lewbloch@gmail.com> - 2011-07-20 21:01 -0700
Re: Arithmetic overflow checking Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-07-21 07:05 -0300
Re: Arithmetic overflow checking supercalifragilisticexpialadiamaticonormalizeringelimatisticantations <supercalifragilisticexpialadiamaticonormalizeringelimatisticantations@averylongandannoyingdomainname.com> - 2011-07-21 06:28 -0400
Re: Arithmetic overflow checking Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-07-21 12:32 +0000
Re: Arithmetic overflow checking Arne Vajhøj <arne@vajhoej.dk> - 2011-07-21 16:58 -0400
Re: Arithmetic overflow checking Patricia Shanahan <pats@acm.org> - 2011-07-21 15:58 -0700
Re: Arithmetic overflow checking Arne Vajhøj <arne@vajhoej.dk> - 2011-07-21 19:14 -0400
Re: Arithmetic overflow checking Martin Gregorie <martin@address-in-sig.invalid> - 2011-07-22 13:07 +0000
Re: Arithmetic overflow checking Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-07-22 17:33 +0000
Re: Arithmetic overflow checking lewbloch <lewbloch@gmail.com> - 2011-07-22 13:36 -0700
Re: Arithmetic overflow checking Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-07-22 23:16 +0000
Re: Arithmetic overflow checking Patricia Shanahan <pats@acm.org> - 2011-07-22 16:50 -0700
Re: Arithmetic overflow checking Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-07-23 20:09 +0000
Re: Arithmetic overflow checking Patricia Shanahan <pats@acm.org> - 2011-07-24 08:56 -0700
Re: Arithmetic overflow checking lewbloch <lewbloch@gmail.com> - 2011-07-23 09:37 -0700
Re: Arithmetic overflow checking David Lamb <dalamb@cs.queensu.ca> - 2011-07-23 11:23 -0400
Re: Arithmetic overflow checking supercalifragilisticexpialadiamaticonormalizeringelimatisticantations <supercalifragilisticexpialadiamaticonormalizeringelimatisticantations@averylongandannoyingdomainname.com> - 2011-07-23 12:04 -0400
Re: Arithmetic overflow checking David Lamb <dalamb@cs.queensu.ca> - 2011-07-23 14:45 -0400
Re: Arithmetic overflow checking lewbloch <lewbloch@gmail.com> - 2011-07-23 11:51 -0700
Re: Arithmetic overflow checking supercalifragilisticexpialadiamaticonormalizeringelimatisticantations <supercalifragilisticexpialadiamaticonormalizeringelimatisticantations@averylongandannoyingdomainname.com> - 2011-07-23 22:39 -0400
Re: Arithmetic overflow checking Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-07-25 10:20 -0700
Re: Arithmetic overflow checking supercalifragilisticexpialadiamaticonormalizeringelimatisticantations <supercalifragilisticexpialadiamaticonormalizeringelimatisticantations@averylongandannoyingdomainname.com> - 2011-07-25 13:29 -0400
Re: Arithmetic overflow checking David Lamb <dalamb@cs.queensu.ca> - 2011-07-25 13:35 -0400
Re: Arithmetic overflow checking lewbloch <lewbloch@gmail.com> - 2011-07-23 09:39 -0700
Re: Arithmetic overflow checking Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-07-23 21:09 +0000
Re: Arithmetic overflow checking Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-07-23 21:24 +0000
Re: Arithmetic overflow checking Arne Vajhøj <arne@vajhoej.dk> - 2011-07-21 16:57 -0400
Re: Arithmetic overflow checking Arne Vajhøj <arne@vajhoej.dk> - 2011-07-20 22:12 -0400
Re: Arithmetic overflow checking Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-07-21 06:41 -0300
Re: Arithmetic overflow checking Arne Vajhøj <arne@vajhoej.dk> - 2011-07-21 16:38 -0400
Re: Arithmetic overflow checking Wanja Gayk <brixomatic@yahoo.com> - 2011-07-06 22:28 +0200
Re: Arithmetic overflow checking Wanja Gayk <brixomatic@yahoo.com> - 2011-07-06 22:30 +0200
Re: Arithmetic overflow checking Tom Anderson <twic@urchin.earth.li> - 2011-07-06 22:32 +0100
Re: Arithmetic overflow checking rop rop <rop049@gmail.com> - 2011-07-07 00:30 -0700
Re: Arithmetic overflow checking Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-07-07 07:54 -0400
Re: Arithmetic overflow checking rop rop <rop049@gmail.com> - 2011-07-07 05:36 -0700
Re: Arithmetic overflow checking Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-07-07 19:11 +0200
Re: Arithmetic overflow checking Tom Anderson <twic@urchin.earth.li> - 2011-07-07 14:21 +0100
Re: Arithmetic overflow checking Stanimir Stamenkov <s7an10@netscape.net> - 2011-07-09 16:34 +0300
Re: Arithmetic overflow checking Roedy Green <see_website@mindprod.com.invalid> - 2011-07-06 22:41 -0700
Re: Arithmetic overflow checking Gene Wirchenko <genew@ocis.net> - 2011-07-07 14:34 -0700
Re: Arithmetic overflow checking Patricia Shanahan <pats@acm.org> - 2011-07-07 14:53 -0700
Re: Arithmetic overflow checking Gene Wirchenko <genew@ocis.net> - 2011-07-07 17:12 -0700
Re: Arithmetic overflow checking lewbloch <lewbloch@gmail.com> - 2011-07-07 17:29 -0700
Re: Arithmetic overflow checking Gene Wirchenko <genew@ocis.net> - 2011-07-08 10:27 -0700
Re: Arithmetic overflow checking lewbloch <lewbloch@gmail.com> - 2011-07-08 13:15 -0700
Re: Arithmetic overflow checking Arne Vajhøj <arne@vajhoej.dk> - 2011-07-19 20:54 -0400
Re: Arithmetic overflow checking markspace <-@.> - 2011-07-19 18:07 -0700
Re: Arithmetic overflow checking Arne Vajhøj <arne@vajhoej.dk> - 2011-07-19 21:31 -0400
Re: Arithmetic overflow checking Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-07-20 07:36 -0300
Re: Arithmetic overflow checking RedGrittyBrick <RedGrittyBrick@spamweary.invalid> - 2011-07-20 11:58 +0100
Re: Arithmetic overflow checking lewbloch <lewbloch@gmail.com> - 2011-07-20 09:51 -0700
Re: Arithmetic overflow checking RedGrittyBrick <RedGrittyBrick@spamweary.invalid> - 2011-07-21 12:11 +0100
Re: Arithmetic overflow checking Martin Gregorie <martin@address-in-sig.invalid> - 2011-07-21 12:43 +0000
Re: Arithmetic overflow checking Tom McGlynn <taqmcglynn@googlemail.com> - 2011-07-21 07:15 -0700
Re: Arithmetic overflow checking lewbloch <lewbloch@gmail.com> - 2011-07-21 07:35 -0700
Re: Arithmetic overflow checking Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-07-21 15:38 +0000
Re: Arithmetic overflow checking lewbloch <lewbloch@gmail.com> - 2011-07-21 09:03 -0700
Re: Arithmetic overflow checking Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-07-21 12:00 -0700
Re: Arithmetic overflow checking Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-07-22 17:16 +0000
Re: Arithmetic overflow checking David Lamb <dalamb@cs.queensu.ca> - 2011-07-23 11:28 -0400
Re: Arithmetic overflow checking Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-07-23 21:03 +0000
Re: Arithmetic overflow checking Henderson <h1@g1.f1> - 2011-07-23 22:55 -0400
Re: Arithmetic overflow checking Patricia Shanahan <pats@acm.org> - 2011-07-24 09:16 -0700
Re: Arithmetic overflow checking markspace <-@.> - 2011-07-24 10:40 -0700
Re: Arithmetic overflow checking Patricia Shanahan <pats@acm.org> - 2011-07-24 10:54 -0700
Re: Arithmetic overflow checking markspace <-@.> - 2011-07-24 11:09 -0700
Re: Arithmetic overflow checking Patricia Shanahan <pats@acm.org> - 2011-07-24 12:53 -0700
Re: Arithmetic overflow checking markspace <-@.> - 2011-07-24 15:15 -0700
Re: Arithmetic overflow checking Patricia Shanahan <pats@acm.org> - 2011-07-24 15:41 -0700
Re: Arithmetic overflow checking Henderson <h1@g1.f1> - 2011-07-25 03:21 -0400
Re: Arithmetic overflow checking Patricia Shanahan <pats@acm.org> - 2011-07-25 00:56 -0700
Re: Arithmetic overflow checking Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-07-25 07:03 -0300
Re: Arithmetic overflow checking Thomas Richter <thor@math.tu-berlin.de> - 2011-07-26 09:43 +0200
Re: Arithmetic overflow checking Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-07-25 11:06 +0000
Re: Arithmetic overflow checking Henderson <h1@g1.f1> - 2011-07-25 11:12 -0400
Re: Arithmetic overflow checking Patricia Shanahan <pats@acm.org> - 2011-07-25 09:09 -0700
Re: Arithmetic overflow checking Patricia Shanahan <pats@acm.org> - 2011-07-25 09:30 -0700
Re: Arithmetic overflow checking David Lamb <dalamb@cs.queensu.ca> - 2011-07-25 13:33 -0400
Re: Arithmetic overflow checking "John B. Matthews" <nospam@nospam.invalid> - 2011-07-26 03:04 -0400
Re: Arithmetic overflow checking Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-07-26 03:28 -0400
Re: Arithmetic overflow checking Henderson <h1@g1.f1> - 2011-07-26 04:53 -0400
Re: Arithmetic overflow checking Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-07-26 11:35 -0400
Re: Arithmetic overflow checking Patricia Shanahan <pats@acm.org> - 2011-07-26 10:48 -0700
Re: Arithmetic overflow checking Arne Vajhøj <arne@vajhoej.dk> - 2011-07-21 17:00 -0400
Re: Arithmetic overflow checking Arne Vajhøj <arne@vajhoej.dk> - 2011-07-20 19:50 -0400
Re: Arithmetic overflow checking Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-07-20 23:21 -0300
Re: Arithmetic overflow checking Martin Gregorie <martin@address-in-sig.invalid> - 2011-07-21 12:52 +0000
Re: Arithmetic overflow checking Henderson <h1@g1.f1> - 2011-07-21 15:58 -0400
Re: Arithmetic overflow checking Arne Vajhøj <arne@vajhoej.dk> - 2011-07-21 17:06 -0400
Re: Arithmetic overflow checking Gene Wirchenko <genew@ocis.net> - 2011-07-20 14:35 -0700
Re: Arithmetic overflow checking Arne Vajhøj <arne@vajhoej.dk> - 2011-07-20 18:22 -0400
Re: Arithmetic overflow checking Gene Wirchenko <genew@ocis.net> - 2011-07-21 14:54 -0700
Re: Arithmetic overflow checking rop rop <rop049@gmail.com> - 2011-07-08 15:34 -0700
Re: Arithmetic overflow checking Gene Wirchenko <genew@ocis.net> - 2011-07-11 08:09 -0700
Re: Arithmetic overflow checking Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-07-11 10:30 -0700
Re: Arithmetic overflow checking Gene Wirchenko <genew@ocis.net> - 2011-07-11 14:43 -0700
Re: Arithmetic overflow checking Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-07-11 14:49 -0700
Re: Arithmetic overflow checking Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-07-17 17:14 +0200
Re: Arithmetic overflow checking David Lamb <dalamb@cs.queensu.ca> - 2011-07-18 19:28 -0400
Re: Arithmetic overflow checking Patricia Shanahan <pats@acm.org> - 2011-07-18 16:36 -0700
Re: Arithmetic overflow checking Arne Vajhøj <arne@vajhoej.dk> - 2011-07-19 21:33 -0400
Re: Arithmetic overflow checking Arne Vajhøj <arne@vajhoej.dk> - 2011-07-19 20:56 -0400
Re: Arithmetic overflow checking Gene Wirchenko <genew@ocis.net> - 2011-07-20 14:36 -0700
Re: Arithmetic overflow checking Arne Vajhøj <arne@vajhoej.dk> - 2011-07-20 18:24 -0400
Re: Arithmetic overflow checking Gene Wirchenko <genew@ocis.net> - 2011-07-21 14:55 -0700
Re: Arithmetic overflow checking Roedy Green <see_website@mindprod.com.invalid> - 2011-07-06 22:43 -0700
Re: Arithmetic overflow checking Jukka Lahtinen <jtfjdehf@hotmail.com.invalid> - 2011-07-07 14:56 +0300
Re: Arithmetic overflow checking "Nasser M. Abbasi" <nma@12000.org> - 2011-07-08 21:27 -0700
Re: Arithmetic overflow checking "Nasser M. Abbasi" <nma@12000.org> - 2011-07-08 21:57 -0700
Re: Arithmetic overflow checking lewbloch <lewbloch@gmail.com> - 2011-07-09 12:16 -0700
Page 3 of 14 — ← Prev page 1 2 [3] 4 5 … 14 Next page →
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2011-07-12 10:48 -0700 |
| Message-ID | <lny603tmop.fsf@nuthaus.mib.org> |
| In reply to | #6122 |
Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
> markspace <-@.> writes:
>> On 7/12/2011 6:16 AM, Stefan Ram wrote:
>>> "BartC"<bc@freeuk.com> writes:
>>>> a+b overflows, but then what?
>>>
>>> This can only be answered given the requirements
>>> specification of a specific project.
>>
>> What I think he's saying is there's no way physically detect the
>> overflow in a language like C which has no exceptions. You'd have to
>> at least introduce some sort of global flag.
>>
>> int c = a + b;
>> if( GLOBAL_OVERFLOW_FLAG ) {
>> printf( "bugger..." );
>> }
>
> Well, yes there is. For example on an addition, if both operands have
> the same sign and the result is the other sign, you had an overflow.
> Analogous conditions exist (which I don't remember off the top of my
> head and am too lazy to look up) exist for subtraction and
> multiplication. Integer division can't overflow.
On many systems, yes, you can detect signed overflow after the fact by
examining the values of the operands and the result. But in C, the
behavior is undefined -- and even on systems that use 2's-complement, an
optimizing compiler can take advantage of that fact and generate code
based on the assumption that overflow never occurs. For example, this:
int x = INT_MAX;
if (x + 1 < x) {
fprintf(stderr, "Overflow!\n");
}
can be optimized away (For example, gcc does this at -O2 and above.)
And yes, integer division can overflow; consider INT_MIN / -1.
> My reading of the question was "OK, you've detected an overflow. Now
> what do you do about it?" and the (correct) answer was, in essence,
> "well, what do you *want* to do about it?"
But detecting the overflow in the first place can be *very* tricky.
--
Keith Thompson (The_Other_Keith) kst-u@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"
[toc] | [prev] | [next] | [standalone]
| From | Martin Gregorie <martin@address-in-sig.invalid> |
|---|---|
| Date | 2011-07-12 16:54 +0000 |
| Message-ID | <ivhu8c$uvd$1@localhost.localdomain> |
| In reply to | #6121 |
On Tue, 12 Jul 2011 09:26:49 -0700, markspace wrote:
> On 7/12/2011 6:16 AM, Stefan Ram wrote:
>> "BartC"<bc@freeuk.com> writes:
>>> a+b overflows, but then what?
>>
>> This can only be answered given the requirements specification of a
>> specific project.
>
>
> What I think he's saying is there's no way physically detect the
> overflow in a language like C which has no exceptions. You'd have to at
> least introduce some sort of global flag.
>
> int c = a + b;
> if( GLOBAL_OVERFLOW_FLAG ) {
> printf( "bugger..." );
> }
Interestingly, the much maligned COBOL has a built-in mitigation for
overflow and a way of trapping it:
Mitigation: since you can specify the number of digits in a numeric data
item (integer or fixed decimal), it follows that the programmer can
control whether overflow can occur and, as the maximum size of a numeric
field is 18 digits, the result field can almost alrays be made long
enough.
Trapping: all computational verbs will accept the ON SIZE ERROR clause
which, despite its name, traps almost all possible calculation errors
including overflow, divide by zero, etc.:
ADD TRANSACTION-VALUE TO TOTAL-VALUE
ON SIZE ERROR PERFORM REPORT-CALCULATION-ERROR.
...and yeah, whoever it was who said Java was verbose has clearly never
written COBOL!
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
[toc] | [prev] | [next] | [standalone]
| From | Gene Wirchenko <genew@ocis.net> |
|---|---|
| Date | 2011-07-12 11:35 -0700 |
| Message-ID | <pt4p1790tm8nrr94lb7plg43u9en3nhls1@4ax.com> |
| In reply to | #6123 |
On Tue, 12 Jul 2011 16:54:36 +0000 (UTC), Martin Gregorie
<martin@address-in-sig.invalid> wrote:
[snip]
>...and yeah, whoever it was who said Java was verbose has clearly never
>written COBOL!
I did, and I have. Java repeats stuff.
Sincerely,
Gene Wirchenko
[toc] | [prev] | [next] | [standalone]
| From | tm <thomas.mertes@gmx.at> |
|---|---|
| Date | 2011-07-12 10:13 -0700 |
| Message-ID | <20f66c93-c4a9-4060-b140-9ab04af2fdaa@b2g2000vbo.googlegroups.com> |
| In reply to | #6121 |
On 12 Jul., 18:26, markspace <-@.> wrote:
> On 7/12/2011 6:16 AM, Stefan Ram wrote:
>
> > "BartC"<b...@freeuk.com> writes:
> >> a+b overflows, but then what?
>
> > This can only be answered given the requirements
> > specification of a specific project.
>
> What I think he's saying is there's no way physically detect the
> overflow in a language like C which has no exceptions.
But there are signals, which can be used for that purpose.
Signals are also used for other exceptional things, like
a division by zero.
> You'd have to at
> least introduce some sort of global flag.
>
> int c = a + b;
> if( GLOBAL_OVERFLOW_FLAG ) {
> printf( "bugger..." );
> }
Checking a global flag is a bad idea, since it does not
allow zero overhead arithmethic overflow detection (by
CPUs which are able to trigger an interrupt on overflow).
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.
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@ieee-dot-org.invalid> |
|---|---|
| Date | 2011-07-12 21:53 -0400 |
| Message-ID | <ivitsb$p4h$1@dont-email.me> |
| In reply to | #6121 |
On 7/12/2011 12:26 PM, markspace wrote:
> On 7/12/2011 6:16 AM, Stefan Ram wrote:
>> "BartC"<bc@freeuk.com> writes:
>>> a+b overflows, but then what?
>>
>> This can only be answered given the requirements
>> specification of a specific project.
>
>
> What I think he's saying is there's no way physically detect the
> overflow in a language like C which has no exceptions.
C has something far more flexible than exceptions: It has
"undefined behavior."
:-)
This thread is dragging on in both comp.lang.java.programmer,
where it began, and in comp.lang.c, to which some doubtless well-
meaning but insufficiently wise person cross-posted it. The two
languages are rather different (in Java, there *is* no integer
overflow in C's sense), and the thread has become at least half-
irrelevant to at least one of the two groups.
Permit me to suggest that people who wish to discuss integer
overflow in C should delete "comp.lang.java.programmer" from their
replies, and likewise people who wish to discuss an alternate Java
that handles overflow differently should delete "comp.lang.c". In
this as in many other matters, the two languages have very little
to do with each other.
--
Eric Sosman
esosman@ieee-dot-org.invalid
[toc] | [prev] | [next] | [standalone]
| From | "MikeP" <mp011011@some.org> |
|---|---|
| Date | 2011-07-14 23:41 -0500 |
| Message-ID | <ivoglh$a3l$1@dont-email.me> |
| In reply to | #6113 |
BartC wrote: > "tm" <thomas.mertes@gmx.at> wrote in message > news:289ad570-65fc-49d8-9cc8-1f15d13ff3e3@gv8g2000vbb.googlegroups.com... > >> And popular CPUs, which do detect integer overflow, do not >> trigger an interupt. This makes zero overhead overflow >> detection impossible. >> >> So software suffers because hardware / CPU designers want >> to save a transistor... > > Even if zero-overhead detection was possible, it's difficult to know > how to make use of this in C. For example: > > int a,b,c; > > c=a+b; > > The a+b overflows, but then what? Then you fix the bug in the program that causes the overflow. > You can't then magically switch > over to: > long long int a,b,c; > > Even /with/ the overhead, it's difficult to see what could follow > such an expression: > > if (overflow(c=a+b)) ... > > In the context of C-based code for implementing auto-ranging, dynamic > types of /another language/, this might be workable, but still > difficult to see how it can be done with zero-overhead. But this is a > limited application (which I wouldn't even attempt in C because it's > so fiddly). > Aborting a program is also a possibility, but this just helps in > debugging, and overheads are less relevant. "JUST" helps debugging? Wouldn't it be nice to get thos MANY, COMMON bugs out of code before it gets deployed? > > (There is a longer thread on this in comp.lang.misc: "Integer > arithmetic" from around start of March 2011.)
[toc] | [prev] | [next] | [standalone]
| From | Gene Wirchenko <genew@ocis.net> |
|---|---|
| Date | 2011-07-15 10:56 -0700 |
| Message-ID | <cov02799v034u4vo10d4gjshjhr9u5vke8@4ax.com> |
| In reply to | #6200 |
On Thu, 14 Jul 2011 23:41:25 -0500, "MikeP" <mp011011@some.org> wrote:
>BartC wrote:
>> "tm" <thomas.mertes@gmx.at> wrote in message
>> news:289ad570-65fc-49d8-9cc8-1f15d13ff3e3@gv8g2000vbb.googlegroups.com...
>>
>>> And popular CPUs, which do detect integer overflow, do not
>>> trigger an interupt. This makes zero overhead overflow
>>> detection impossible.
>>>
>>> So software suffers because hardware / CPU designers want
>>> to save a transistor...
>>
>> Even if zero-overhead detection was possible, it's difficult to know
>> how to make use of this in C. For example:
>>
>> int a,b,c;
>>
>> c=a+b;
>>
>> The a+b overflows, but then what?
>
>Then you fix the bug in the program that causes the overflow.
First, you have to detect the overflow. Since the language does
not make that easy, you may miss it.
[snip]
Sincerely,
Gene Wirchenko
[toc] | [prev] | [next] | [standalone]
| From | "MikeP" <mp011011@some.org> |
|---|---|
| Date | 2011-07-15 21:27 -0500 |
| Message-ID | <ivqsuq$7us$1@dont-email.me> |
| In reply to | #6216 |
Gene Wirchenko wrote: > On Thu, 14 Jul 2011 23:41:25 -0500, "MikeP" <mp011011@some.org> wrote: > >> BartC wrote: >>> "tm" <thomas.mertes@gmx.at> wrote in message >>> news:289ad570-65fc-49d8-9cc8-1f15d13ff3e3@gv8g2000vbb.googlegroups.com... >>> >>>> And popular CPUs, which do detect integer overflow, do not >>>> trigger an interupt. This makes zero overhead overflow >>>> detection impossible. >>>> >>>> So software suffers because hardware / CPU designers want >>>> to save a transistor... >>> >>> Even if zero-overhead detection was possible, it's difficult to know >>> how to make use of this in C. For example: >>> >>> int a,b,c; >>> >>> c=a+b; >>> >>> The a+b overflows, but then what? >> >> Then you fix the bug in the program that causes the overflow. > > First, you have to detect the overflow. Since the language does > not make that easy, you may miss it. > To me, he seemingly implied that the overflow WOULD be detected after the addition in his example and that he was asking how to handle it.
[toc] | [prev] | [next] | [standalone]
| From | bugbear <bugbear@trim_papermule.co.uk_trim> |
|---|---|
| Date | 2011-07-20 09:22 +0100 |
| Message-ID | <_bednSTX_oyqDbvTnZ2dnUVZ7radnZ2d@brightview.co.uk> |
| In reply to | #6039 |
tm wrote: > > And popular CPUs, which do detect integer overflow, do not > trigger an interupt. This makes zero overhead overflow > detection impossible. > > So software suffers because hardware / CPU designers want > to save a transistor... Some software relies on overflows NOT triggering anything - encryption software, for example. I think an interrupt every time THAT overflows would have performance implications ;-) BugBear
[toc] | [prev] | [next] | [standalone]
| From | tm <thomas.mertes@gmx.at> |
|---|---|
| Date | 2011-07-20 10:51 -0700 |
| Message-ID | <65991dc2-9acf-4867-b54a-8569b9683320@l37g2000yqd.googlegroups.com> |
| In reply to | #6300 |
On 20 Jul., 10:22, bugbear <bugbear@trim_papermule.co.uk_trim> wrote: > tm wrote: > > > And popular CPUs, which do detect integer overflow, do not > > trigger an interupt. This makes zero overhead overflow > > detection impossible. > > > So software suffers because hardware / CPU designers want > > to save a transistor... > > Some software relies on overflows NOT triggering > anything - encryption software, for example. > > I think an interrupt every time THAT overflows > would have performance implications ;-) In C and other languages integer values are used for two things: 1. Integer arithmetic ( + - * / ) 2. Bit manipulation (shifts, masks, logical and, logical or) Bit manipulation works best without overflow detection. Your example of encryption software is IMHO a bit manipulation. I am interested in integer arithmetic with overflow checking. The programmer should decide, if he wants overflow checking. E.g. with a compiler switch, different types or pragmas. In C unsigned integer types are defined to have no overflow checking, while signed integer types have an undefined behavior, when an overflow occurs. Gcc and clang have the flag -ftrapv, which checks the signed operations +, +, *, / and % for overflow. Existing code should continue to work in the way it was defined (no overflow checking or undefined behavior), but the programmer should have the possibility to use overflow checking. The CPUs and the compilers should be changed to allow cheap overflow checking (with zero cost when no overflow happens). This can IMHO only be done when an overflow raises an exception (or a signal in a language which does not support exceptions). An approach with an overflow flag will probably not allow zero overhead when no overflow occurs. A new language (or a language variant) has other possibilities, since there is no backward compatibility. For my own language I want to use overflow checking. I use C as implementation language for interpreter and runtime library and as backend for the compiler. A such I only can support what C, the C compiler, the OS and the hardware allows me to do. If languages like C, C++ and Java start to consider overflow checking as important, the CPU designers and compiler writers will be motivated to support it. Correct results are the most important thing you want from an computer. Sometimes errors are accepted, just to get maximum performance. Some people accept errors, because they want no exception. But this are corner cases, which should be handled as special. Correct results (with overflow checking) should be the normal case and everything else should be handled as special case (e.g. a pragma to ignore overflow). 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.
[toc] | [prev] | [next] | [standalone]
| From | gordonb.3urm7@burditt.org (Gordon Burditt) |
|---|---|
| Date | 2011-07-20 15:39 -0500 |
| Message-ID | <JLWdnVqh_ZZrobrTnZ2dnUVZ_gSdnZ2d@posted.internetamerica> |
| In reply to | #6312 |
>> Some software relies on overflows NOT triggering >> anything - encryption software, for example. >> >> I think an interrupt every time THAT overflows >> would have performance implications ;-) I think there would be more than performance implications: there isn't any easy way, and certainly not portable way, to tell specifically where the overflow happened so it can be ignored. Aborting the program certainly will have (infinite) performance implications. > In C and other languages integer values are used for two > things: > > 1. Integer arithmetic ( + - * / ) > 2. Bit manipulation (shifts, masks, logical and, logical or) Bit manipulation may include integer arithmetic also: consider checksums. You can't tell the difference between (1) and (2) by looking at the machine instructions. > Bit manipulation works best without overflow detection. > Your example of encryption software is IMHO a bit > manipulation. I am interested in integer arithmetic with > overflow checking. It is often not possible to tell the difference between intended bit manipulation and intended integer arithmetic. (x*2) is sometimes written as (x << 1), and under some circumstances *needs* an overflow check. One good indication that bit manipulation is intended seems to be the use of an unsigned type in C. > The programmer should decide, if he wants overflow checking. > E.g. with a compiler switch, different types or pragmas. A compiler switch alone would seem to be usually too coarse-grained. I prefer a special operator/function which evaluates its arguments with or without overflow checking. E.g. nooverflowcheck(checksum += buffer[i]); although this has problems when there are function calls in the expression. I prefer that *both* nooverflowcheck() and overflowcheck() exist, to override more global defaults of pragmas and compiler options. I can also see the possibility of an expression which needs over a dozen pragmas in it. Pragma may also be too coarse-grained in some situations. > In C unsigned integer types are defined to have no overflow > checking, while signed integer types have an undefined > behavior, when an overflow occurs. Gcc and clang have the > flag -ftrapv, which checks the signed operations +, +, *, / > and % for overflow. GCC omits mention that -ftrapv checks signed / or % operations. Does it really check that? No mention is made of checking on unary minus. Also blatantly missing is any check on overflow during conversions such as long to short or int to char. Also, as others have brought up, recent GCC versions break -ftrapv completely. > Existing code should continue to work in the way it was > defined (no overflow checking or undefined behavior), but > the programmer should have the possibility to use overflow > checking. >The CPUs and the compilers should be changed to > allow cheap overflow checking (with zero cost when no > overflow happens). I don't believe this (zero cost on no overflow) is possible. Conventional wisdom says that conditional branches are oh-so-horribly-expensive on modern CPUs. I expect that conditional traps are approximately equally expensive. I expect a cost in the pipeline even for a predicted-trap-not-taken actual trap-not-taken overflow check, even if it's just failure to pipeline one more instruction. Also, you need a way to distinguish between overflow-trapping and non-overflow-trapping instructions. That seems to have several possibilities: (1) Use a check/don't check bit in the instruction. Since instruction-set designers try to use most of the bit combinations effectively, this means pushing other instructions into a longer format or out of the instruction set entirely. Some code is going to get longer. Here you're hiding the cost in the instruction set design. (2) Use a status bit to control checking. This implies that the compiler has to insert instructions to turn the bit on and off, and there's a need for saving and restoring the state of that bit. Those instructions take memory and have a cost, even if it's the opportunity cost of not being able to pipeline another instruction. If there's a spare bit in an existing status register, this might not require additional instructions in the instruction set, making use of existing instructions to set and clear bits in the status register, and save and restore it. Existing interrupt handler code may not need to be changed. (3) Explicitly check for overflow. This could be ftrapv, or a conditional branch or call to a routine that raises a signal. Note that the conditional branch method loses information on exactly where the overflow happened. These instructions take memory and time. >This can IMHO only be done when an > overflow raises an exception (or a signal in a language > which does not support exceptions). An approach with an > overflow flag will probably not allow zero overhead when > no overflow occurs. I'm not sure I believe in "zero overhead overflow checking". > A new language (or a language variant) has other > possibilities, since there is no backward compatibility. > For my own language I want to use overflow checking. > I use C as implementation language for interpreter and > runtime library and as backend for the compiler. A such > I only can support what C, the C compiler, the OS and > the hardware allows me to do. I think using longjmp out of a signal handler, currently undefined behavior, could be made defined with restrictions for the overflow signal. > If languages like C, C++ and Java start to consider > overflow checking as important, the CPU designers and > compiler writers will be motivated to support it. > > Correct results are the most important thing you want > from an computer. This depends on the application. Rolling over and dying is not always acceptable, *especially* in certain safety-critical applications like flight control. "scramming" a nuclear reactor to shut it down is acceptable, but shutting down the cooling system is not. Shutting down an ISP's primary nameserver because one query overflowed a statistics counter, or even something important to the query, is not acceptable (but failing a single query is). > Sometimes errors are accepted, just to get maximum > performance. Some people accept errors, because they want > no exception. But this are corner cases, which should > be handled as special. > Correct results (with overflow checking) should be > the normal case and everything else should be handled > as special case (e.g. a pragma to ignore overflow).
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2011-07-21 12:12 +0100 |
| Message-ID | <j091m5$del$1@dont-email.me> |
| In reply to | #6312 |
"tm" <thomas.mertes@gmx.at> wrote in message news:65991dc2-9acf-4867-b54a-8569b9683320@l37g2000yqd.googlegroups.com... > Correct results are the most important thing you want > from an computer. > Sometimes errors are accepted, just to get maximum > performance. Or sometimes people can assume there will be no error because they know the program. If you are using C to implement another language, especially a 'softer' language where the user expects the language to hold his hand a lot more, then that is a bit of a special case. Here, problems such as trapping bounds-errors and overflows can be solved by the /implementer/ writing the appropriate C code, taking advantage of any built-in facilities for these, but not depending on them. If a badly handled bounds or overflow error occurs in the (user's) program, then that is the responsibility of the implementer; you can't blame the short-comings of C for that. People writing directly in C (who are not using C to implement another system) can't easily and elegantly make use of things such as overflow checks and array bounds checking. With an implementer however, clunky code may not be an issue (since the code will only appear in one place, or will be in generated code that no-one will ever see). (And what if the language being implemented has a range type, such as Int: 1000 .. 2000; you would surely need to check overflow *and* underflow, and you can't expect C, the OS or the hardware to give you much help here. Even more so if you have a type such as (2,4,6,10), ie. only containing those values. In this case, these checks need to be built on top of C (or whatever implementation language is used); and the same can surely be done for anything else.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@ieee-dot-org.invalid> |
|---|---|
| Date | 2011-07-10 09:28 -0400 |
| Message-ID | <ivc9ft$j7e$1@dont-email.me> |
| In reply to | #6032 |
On 7/10/2011 5:47 AM, China Blue Dolls wrote:
>
> In C the array size is not part of the type or value, so there is nothing to
> check.
No; the size (element count) is part of an array's type. Your
compiler will confirm this for you by issuing a diagnostic for
char matrix[5][7]; /* five char[7] arrays */
char (*nine)[9]; /* pointer to char[9] */
nine = matrix; /* point it at the first char[7] */
> C integer arithmetic is always modulo M, for some large M (like 2**32 or 2**64).
> So the concept of overflow does not apply.
This is true only for `unsigned' integer arithmetic. Signed
integer arithmetic is in fact vulnerable to overflow.
--
Eric Sosman
esosman@ieee-dot-org.invalid
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2011-07-10 06:52 -0700 |
| Message-ID | <d2429ed6-b6dc-41e6-8c3b-888bbbc8fe6c@s2g2000vbw.googlegroups.com> |
| In reply to | #6043 |
On Jul 10, 4:28 pm, Eric Sosman <esos...@ieee-dot-org.invalid> wrote: > > This is true only for `unsigned' integer arithmetic. Signed > integer arithmetic is in fact vulnerable to overflow. > All arithmetic is vulnerable to overflow. The question is whether the system reports and error or gives wrong results. Sometimes wrong results are better than errors, for instance in video games, but only rarely. -- Learn all about MPI Tutorial on my website: http://www.malcolmmclean.site11.com/www
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2011-07-10 14:47 -0700 |
| Message-ID | <ln62n9x0ym.fsf@nuthaus.mib.org> |
| In reply to | #6045 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Jul 10, 4:28 pm, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
>> This is true only for `unsigned' integer arithmetic. Signed
>> integer arithmetic is in fact vulnerable to overflow.
>>
> All arithmetic is vulnerable to overflow. The question is whether the
> system reports and error or gives wrong results. Sometimes wrong
> results are better than errors, for instance in video games, but only
> rarely.
All arithmetic that's intended to model (a subset of) the real
numbers with the usual mathematical operations is vulnerable to
overflow. (Even arbitrary-precision packages can run out of memory.)
But C unsigned arithmetic, for example *doesn't* model normal real
arithmetic; it models arithmetic modulo 2**N and is not vulnerable
to overflow. (Wraparound is not overflow; it yields the correct
wrapped result.)
--
Keith Thompson (The_Other_Keith) kst-u@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"
[toc] | [prev] | [next] | [standalone]
| From | "MikeP" <mp011011@some.org> |
|---|---|
| Date | 2011-07-14 23:07 -0500 |
| Message-ID | <ivoed5$lj$1@dont-email.me> |
| In reply to | #6043 |
Eric Sosman wrote: > On 7/10/2011 5:47 AM, China Blue Dolls wrote: >> >> In C the array size is not part of the type or value, so there is >> nothing to check. > > No; the size (element count) is part of an array's type. Your > compiler will confirm this for you by issuing a diagnostic for > > char matrix[5][7]; /* five char[7] arrays */ > char (*nine)[9]; /* pointer to char[9] */ > nine = matrix; /* point it at the first char[7] */ > >> C integer arithmetic is always modulo M, for some large M (like >> 2**32 or 2**64). So the concept of overflow does not apply. > > This is true only for `unsigned' integer arithmetic. Signed > integer arithmetic is in fact vulnerable to overflow. And if you take "overflow" to mean "can do something undesireable (wrap) without warning", so does unsigned arith. To say "So the concept of overflow does not apply" seems to attempt to dismiss the behavior as being OK somehow instead of recognizing the deficiency that it is most of the time.
[toc] | [prev] | [next] | [standalone]
| From | Joshua Cranmer <Pidgeot18@verizon.invalid> |
|---|---|
| Date | 2011-07-10 12:25 -0400 |
| Message-ID | <ivcjp6$mkm$1@dont-email.me> |
| In reply to | #6032 |
On 07/10/2011 05:47 AM, China Blue Dolls wrote: > In article<3797038f-22d1-40b2-8c12-60db5a0976b8@t5g2000yqj.googlegroups.com>, >> 2. check if an 32-bit (or 8-bit, 16-bit, 64-bit, ...) >> computation overflows. > > C integer arithmetic is always modulo M, for some large M (like 2**32 or 2**64). > So the concept of overflow does not apply. That is only true for unsigned integers; signed integer overflow is undefined. -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2011-07-10 10:47 -0500 |
| Message-ID | <4mhj17h520a6oh12r3p5tbfjc59qphdgba@4ax.com> |
| In reply to | #6029 |
On Sun, 10 Jul 2011 01:47:25 -0700 (PDT), tm <thomas.mertes@gmx.at> wrote: >On 8 Jul., 05:04, Patricia Shanahan <p...@acm.org> wrote: >> On 7/7/2011 5:51 PM, Peter Duniho wrote: >> ... >> >> > I would not worry about the "simple" or "efficient" criteria. IMHO, if >> > one is deciding to apply overflow checking to every computation, one has >> > already abandoned the hope of efficiency. >> >> Not necessarily. I assumed a couple of decades ago that array index >> checking would be impossibly inefficient, but it seems to work fine in >> Java. > >And in other languages, like Pascal, Ada and Seed7, as well. A good compiler can often limit the number of time array bounds checks to much less than every access. For example, a sequence of uses of the same index value obvious only needs the index checked once, or a loop with bounds that don't change during the loop can often move the check ahead of the loop. >> I suspect that having integer range types would be a major help. >> When I'm working out whether an int can overflow, I often think in terms >> of the ranges of inputs to calculations. A compiler would be able to >> tell that adding a digit to a digit always fits in the range [0,18]. > >I think there are two things: > > 1. range checks (like value fits in [0,18]). > 2. check if an 32-bit (or 8-bit, 16-bit, 64-bit, ...) > computation overflows. > >In the 1. case a compiler could generate code that does >the computation and checks the range afterwards. >In the 2. case a computation could result in wrong data, >because the overflow was silently ignored. In this case >either some checks must be done before the computation or >the overfow condition is recognized during or after the >computation. In an ideal world the hardware would do this. > >A CPU could (in theory) easily recognize the overflow >and generate an interrupt. This way normal computations >(without overflow) would have no extra cost. AFAIK >commonly used CPUs do not have this possibility. They >have some FLAG, which is set when an overflow occurred. >But there is no possibility to cause an interrupt, when >the overflow FLAG is set. So code, which checks for >overflow, must check this flag after every computation. >Needless to say: Normal computations (without overflow) >are slowed down by this checks. > >Because of this slow down most compilers and virtual >machines (AFAIK inluding the JVM) have no overflow >checking. > >In other words: A missing hardware feature: > > Trigger interupt when overflow flag is set. > >Causes compilers and JVMs to omit overflow checks. S/360 and its descendents have such a feature (for both binary and decimal arithmetic), which can be enabled by applications by setting a bit in the PSW. Nobody uses it. It doesn't do quite everything (for example, the multiply instruction produces double width results, and doesn't ever overflow, but you obviously have an issue if you're going to store that result back in a single width variable). It also messes up enough code, that what you'd really want is a separate set of instruction that did or didn't trap on overflow (S/360 already has a number of separate signed and unsigned binary arithmetic instructions, the unsigned ones don't trap on "overflow"). In a similar vein, SNaNs are only rarely actually set to trap, even though a lot of hardware that support IEEE math does support doing that.
[toc] | [prev] | [next] | [standalone]
| From | Gene Wirchenko <genew@ocis.net> |
|---|---|
| Date | 2011-07-11 07:58 -0700 |
| Message-ID | <fn3m17p1p5ipsit6ltmg6rqtlcf5kvdmep@4ax.com> |
| In reply to | #6029 |
On Sun, 10 Jul 2011 01:47:25 -0700 (PDT), tm <thomas.mertes@gmx.at>
wrote:
[snip]
>In other words: A missing hardware feature:
>
> Trigger interupt when overflow flag is set.
>
>Causes compilers and JVMs to omit overflow checks.
No, it does not. Coupled with the idea of speed at all costs,
yes.
I think the safe option should be on by default. If you really
need the speed, then you can make the decision to override.
Most of the time, the speed is not required. I will take
slightly slower, correct results over fast, possibly wrong results.
Sincerely,
Gene Wirchenko
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2011-07-11 10:48 -0700 |
| Message-ID | <468f2805-8ba2-4931-8baa-b3b45d838532@ct4g2000vbb.googlegroups.com> |
| In reply to | #6071 |
On Jul 11, 5:58 pm, Gene Wirchenko <ge...@ocis.net> wrote: > > Most of the time, the speed is not required. I will take > slightly slower, correct results over fast, possibly wrong results. > The game keeps on changing. For instance modern space invaders are slowed down by the need to normalise their vectors for lighting. Most of the rest of the code is either handled by special rasterisers, or is insignificant in the larger scheme of things. However they used to crawl about the screen unless you pulled all the layers of indirection and gift-wrapping and bounds checking away. -- Learn MPI (message passing interface). On my website, http://www.malcolmmclean.site11.com/www
[toc] | [prev] | [next] | [standalone]
Page 3 of 14 — ← Prev page 1 2 [3] 4 5 … 14 Next page →
Back to top | Article view | comp.lang.java.programmer
csiph-web