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 5 of 14 — ← Prev page 1 … 3 4 [5] 6 7 … 14 Next page →
| From | Martin Gregorie <martin@address-in-sig.invalid> |
|---|---|
| Date | 2011-07-12 21:08 +0000 |
| Message-ID | <ivid4r$34o$1@localhost.localdomain> |
| In reply to | #6132 |
On Tue, 12 Jul 2011 13:23:40 -0700, Gene Wirchenko wrote: > > I also suggest that they build a time machine and go for a ride > on a certain Ariane 5 launch. > An out-of-range signal might have been the initial clause[1] but the real problem was that this exception caused an diagnostic bit pattern to be written to the SRI's (Inertial Reference System's) normal output channel, where the OBC (On Board Computer) interpreted it as flight data by failing to recognise it as an exception message. Unfortunately, by treating it as flight data, the OBC interpreted it as requiring full engine deflection, causing the Ariane 5 to yaw violently. Unsurprisingly, being side-on at high airspeed caused it to break up. There real cause of the crash was using a poorly documented A4 SRI without fully understanding its designed-in operating parameters or ensuring that they were reset to interpret standard A5 operating conditions as normal and within limits and then compounding the problem by not designing the OBC to recognise SRI exception messages. IOW, this crash was more a case of poor documentation and design rather than arithmetic overflow. The full report is here: http://www.di.unito.it/~damiani/ariane5rep.html [1] The instrument causing the problem was an unmodified Ariane 4 SRI which raised an out-of-limits exception when the normal Ariane 5 trajectory exceeded a permitted Ariane 4 horizontal velocity limit. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
[toc] | [prev] | [next] | [standalone]
| From | lewbloch <lewbloch@gmail.com> |
|---|---|
| Date | 2011-07-12 14:48 -0700 |
| Message-ID | <693db00d-83be-4830-a1fc-262d9d34d672@z15g2000pre.googlegroups.com> |
| In reply to | #6133 |
Martin Gregorie wrote: > Gene Wirchenko wrote: >> I also suggest that they build a time machine and go for a ride >> on a certain Ariane 5 launch. > > An out-of-range signal might have been the initial clause[1] but the real > problem was that this exception caused an diagnostic bit pattern to be > written to the SRI's (Inertial Reference System's) normal output channel, > where the OBC (On Board Computer) interpreted it as flight data by > failing to recognise it as an exception message. Unfortunately, by > treating it as flight data, the OBC interpreted it as requiring full > engine deflection, causing the Ariane 5 to yaw violently. Unsurprisingly, > being side-on at high airspeed caused it to break up. > > There real cause of the crash was using a poorly documented A4 SRI > without fully understanding its designed-in operating parameters or > ensuring that they were reset to interpret standard A5 operating > conditions as normal and within limits and then compounding the problem > by not designing the OBC to recognise SRI exception messages. > > IOW, this crash was more a case of poor documentation and design rather > than arithmetic overflow. > > The full report is here:http://www.di.unito.it/~damiani/ariane5rep.html > > [1] The instrument causing the problem was an unmodified Ariane 4 SRI > which raised an out-of-limits exception when the normal Ariane 5 > trajectory exceeded a permitted Ariane 4 horizontal velocity limit. > In other words, this was a case where there *was* an out-of-range exception, thus it makes the exact opposite point to the one Gene presumably wanted to support. -- Lew
[toc] | [prev] | [next] | [standalone]
| From | Gene Wirchenko <genew@ocis.net> |
|---|---|
| Date | 2011-07-12 15:24 -0700 |
| Message-ID | <naip179apc4bmtnmlm3mb6t3ru9o179qi0@4ax.com> |
| In reply to | #6135 |
n Tue, 12 Jul 2011 14:48:47 -0700 (PDT), lewbloch <lewbloch@gmail.com>
wrote:
>Martin Gregorie wrote:
[snip]
>> [1] The instrument causing the problem was an unmodified Ariane 4 SRI
>> which raised an out-of-limits exception when the normal Ariane 5
>> trajectory exceeded a permitted Ariane 4 horizontal velocity limit.
...the Ariane 5 having more powerful engines.
>In other words, this was a case where there *was* an out-of-range
>exception, thus it makes the exact opposite point to the one Gene
>presumably wanted to support.
The data I read was that the exception was not handled. IIRC,
debugging got interpreted as navigational data.
Sincerely,
Gene Wirchenko
[toc] | [prev] | [next] | [standalone]
| From | lewbloch <lewbloch@gmail.com> |
|---|---|
| Date | 2011-07-12 16:09 -0700 |
| Message-ID | <9d33ce51-1f6a-4782-8098-a051456532ca@m6g2000prh.googlegroups.com> |
| In reply to | #6136 |
Gene Wirchenko wrote: > lewbloch wrote: >> Martin Gregorie wrote: > > [snip] > >>> [1] The instrument causing the problem was an unmodified Ariane 4 SRI >>> which raised an out-of-limits exception when the normal Ariane 5 >>> trajectory exceeded a permitted Ariane 4 horizontal velocity limit. > > ...the Ariane 5 having more powerful engines. > >> In other words, this was a case where there *was* an out-of-range >> exception, thus it makes the exact opposite point to the one Gene >> presumably wanted to support. > > The data I read was that the exception was not handled. IIRC, > debugging got interpreted as navigational data. > Precisely. There was an exception, and it was not handled. Having the exception was not enough. -- Lew
[toc] | [prev] | [next] | [standalone]
| From | Gene Wirchenko <genew@ocis.net> |
|---|---|
| Date | 2011-07-13 10:38 -0700 |
| Message-ID | <8vlr17d90u9cb63hf64hhstaoamdgsb5je@4ax.com> |
| In reply to | #6139 |
On Tue, 12 Jul 2011 16:09:04 -0700 (PDT), lewbloch
<lewbloch@gmail.com> wrote:
>Gene Wirchenko wrote:
>> lewbloch wrote:
>>> Martin Gregorie wrote:
>>
>> [snip]
>>
>>>> [1] The instrument causing the problem was an unmodified Ariane 4 SRI
>>>> which raised an out-of-limits exception when the normal Ariane 5
>>>> trajectory exceeded a permitted Ariane 4 horizontal velocity limit.
>>
>> ...the Ariane 5 having more powerful engines.
>>
>>> In other words, this was a case where there *was* an out-of-range
>>> exception, thus it makes the exact opposite point to the one Gene
>>> presumably wanted to support.
>>
>> The data I read was that the exception was not handled. IIRC,
>> debugging got interpreted as navigational data.
>Precisely. There was an exception, and it was not handled. Having
>the exception was not enough.
No surprise there. Most of us understand that exceptions have to
be handled as well as thrown.
Sincerely,
Gene Wirchenko
[toc] | [prev] | [next] | [standalone]
| From | Patricia Shanahan <pats@acm.org> |
|---|---|
| Date | 2011-07-13 11:00 -0700 |
| Message-ID | <M6CdnZulH5XYQIDTnZ2dnUVZ_oKdnZ2d@earthlink.com> |
| In reply to | #6165 |
On 7/13/2011 10:38 AM, Gene Wirchenko wrote: > On Tue, 12 Jul 2011 16:09:04 -0700 (PDT), lewbloch > <lewbloch@gmail.com> wrote: > >> Gene Wirchenko wrote: >>> lewbloch wrote: >>>> Martin Gregorie wrote: >>> >>> [snip] >>> >>>>> [1] The instrument causing the problem was an unmodified Ariane 4 SRI >>>>> which raised an out-of-limits exception when the normal Ariane 5 >>>>> trajectory exceeded a permitted Ariane 4 horizontal velocity limit. >>> >>> ...the Ariane 5 having more powerful engines. >>> >>>> In other words, this was a case where there *was* an out-of-range >>>> exception, thus it makes the exact opposite point to the one Gene >>>> presumably wanted to support. >>> >>> The data I read was that the exception was not handled. IIRC, >>> debugging got interpreted as navigational data. > >> Precisely. There was an exception, and it was not handled. Having >> the exception was not enough. > > No surprise there. Most of us understand that exceptions have to > be handled as well as thrown. I think the lesson we need to learn from the Ariane failure is that adding a check removes one type of risk, but the cost of two forms of additional risk: 1. The check gives a false positive result. 2. There is a bug in the handling of the error report. Patricia
[toc] | [prev] | [next] | [standalone]
| From | lewbloch <lewbloch@gmail.com> |
|---|---|
| Date | 2011-07-13 12:16 -0700 |
| Message-ID | <b8a1386b-9325-4333-a978-7f7eb2c4254f@g3g2000prf.googlegroups.com> |
| In reply to | #6165 |
On Jul 13, 10:38 am, Gene Wirchenko <ge...@ocis.net> wrote: > On Tue, 12 Jul 2011 16:09:04 -0700 (PDT), lewbloch > > > > > > > > > > <lewbl...@gmail.com> wrote: > >Gene Wirchenko wrote: > >> lewbloch wrote: > >>> Martin Gregorie wrote: > > >> [snip] > > >>>> [1] The instrument causing the problem was an unmodified Ariane 4 SRI > >>>> which raised an out-of-limits exception when the normal Ariane 5 > >>>> trajectory exceeded a permitted Ariane 4 horizontal velocity limit. > > >> ...the Ariane 5 having more powerful engines. > > >>> In other words, this was a case where there *was* an out-of-range > >>> exception, thus it makes the exact opposite point to the one Gene > >>> presumably wanted to support. > > >> The data I read was that the exception was not handled. IIRC, > >> debugging got interpreted as navigational data. > >Precisely. There was an exception, and it was not handled. Having > >the exception was not enough. > > No surprise there. Most of us understand that exceptions have to > be handled as well as thrown. > Apparently it was a surprise to the Ariane 5 folks. But you brought up the case history in the first place. What was the point if not that exceptions need to be handled? Isn't the problem with the rocket exactly that exceptions weren't handled, despite your attempt to palm that off as obvious? Or are you just shifting ground now that your apparent original point turns out not to be supported by the Ariane failure? It certainly was not that overflow exceptions are good all by themselves, since that didn't help the rocket in question. The lesson I derive is that nothing is too simple, trivial or obvious to overlook. Whether it's metric vs. English system of length that makes one miss Mars, or failure to handle an exception that makes a rocket blow up, despite that *obviously* one must use consistent units, and *obviously* one must handle exceptions when thrown, we still need to be diligent about such "obvious" matters. So put aside your pseudo-condescension and let's learn the lessons these case histories teach us. -- Lew
[toc] | [prev] | [next] | [standalone]
| From | Gene Wirchenko <genew@ocis.net> |
|---|---|
| Date | 2011-07-13 13:10 -0700 |
| Message-ID | <cjur17t4no7dbtbmjrbl8kqmi4v5oj4qi6@4ax.com> |
| In reply to | #6169 |
On Wed, 13 Jul 2011 12:16:22 -0700 (PDT), lewbloch
<lewbloch@gmail.com> wrote:
>On Jul 13, 10:38 am, Gene Wirchenko <ge...@ocis.net> wrote:
>> On Tue, 12 Jul 2011 16:09:04 -0700 (PDT), lewbloch
>> <lewbl...@gmail.com> wrote:
>> >Gene Wirchenko wrote:
[snip]
>> No surprise there. Most of us understand that exceptions have to
>> be handled as well as thrown.
>>
>
>Apparently it was a surprise to the Ariane 5 folks.
No. From what I read, in the area of the error, there were some
places where handling was judged needed and some not. What they did
about it was not adequate.
>But you brought up the case history in the first place. What was the
>point if not that exceptions need to be handled? Isn't the problem
First, you need a mechanism for them. Then, you handle them.
>with the rocket exactly that exceptions weren't handled, despite your
>attempt to palm that off as obvious? Or are you just shifting ground
But it is obvious to a professional. It is fairly basic.
>now that your apparent original point turns out not to be supported by
>the Ariane failure?
Exceptions were not dealt with properly. Not having them when
one should is another case of this.
>It certainly was not that overflow exceptions are good all by
>themselves, since that didn't help the rocket in question.
A professional would understand that they have to be used
properly, too.
>The lesson I derive is that nothing is too simple, trivial or obvious
>to overlook. Whether it's metric vs. English system of length that
>makes one miss Mars, or failure to handle an exception that makes a
>rocket blow up, despite that *obviously* one must use consistent
>units, and *obviously* one must handle exceptions when thrown, we
>still need to be diligent about such "obvious" matters.
Of course.
>So put aside your pseudo-condescension and let's learn the lessons
>these case histories teach us.
My condescension? Look in a mirror.
I assume that professionals will understand some pretty basic
things. For example, if we have an exception mechanism, that we do
something about the exceptions. Were I to explain every such detail,
it would be being condescending.
Sincerely,
Gene Wirchenko
[toc] | [prev] | [next] | [standalone]
| From | markspace <-@.> |
|---|---|
| Date | 2011-07-13 13:21 -0700 |
| Message-ID | <ivkuor$9sc$1@dont-email.me> |
| In reply to | #6169 |
On 7/13/2011 12:16 PM, lewbloch wrote: > The lesson I derive is that nothing is too simple, trivial or obvious > to overlook. What I got from reading that is that the root problem was that the range of values that the sensor was capable of producing was not understood. Either or both physically producing, or would produce under normal (or abnormal) system operation. It was a failure to understand the the design, and its parameters. That failure of understanding was then propagated down to the code level. "We don't need to protect this because an out of range can't happen." Somewhere, somehow, somebody has to ultimately understand what the system does, and when. If you don't have that, then no amount of general wolf-fencing (i.e., catching exceptions) will help, because you won't know that the exception even means, let alone what to do about it.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2011-07-13 13:41 -0700 |
| Message-ID | <lnd3hdrjzk.fsf@nuthaus.mib.org> |
| In reply to | #6171 |
markspace <-@.> writes:
> On 7/13/2011 12:16 PM, lewbloch wrote:
>> The lesson I derive is that nothing is too simple, trivial or obvious
>> to overlook.
>
>
> What I got from reading that is that the root problem was that the range
> of values that the sensor was capable of producing was not understood.
> Either or both physically producing, or would produce under normal (or
> abnormal) system operation.
As I recall, the range of values the sensor was capable of producing was
understood correctly *when the code was written*.
The problem is that the code was written for the Ariane 4. Management
decided to re-use the same code, with no modifications, on the Ariane 5
-- on which the valid range of values from the sensor was quite
different.
> It was a failure to understand the the design, and its parameters. That
> failure of understanding was then propagated down to the code level.
> "We don't need to protect this because an out of range can't happen."
Decisions had to be made when the code was written about which
exceptions to handle, and which to assume couldn't happen.
Handling them all wasn't an option because it would have slowed
down the system enough so it wouldn't work at all. The particular
decisions were correct for Ariane 4.
> Somewhere, somehow, somebody has to ultimately understand what the
> system does, and when. If you don't have that, then no amount of
> general wolf-fencing (i.e., catching exceptions) will help, because you
> won't know that the exception even means, let alone what to do about it.
Given the decision to re-use the same code with no changes for a
new rocket (when the code wasn't designed for cross-rocket portability
in the first place), an improperly handled exception was just one of many
ways that it could have gone wrong.
(All this is based on my rather vague recollection of my partial reading
of the report.)
--
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 | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2011-07-14 21:10 -0500 |
| Message-ID | <gn7v17d4ljhjsndhksgk4f1584a135u6cf@4ax.com> |
| In reply to | #6172 |
On Wed, 13 Jul 2011 13:41:51 -0700, Keith Thompson <kst-u@mib.org> wrote: >markspace <-@.> writes: >> On 7/13/2011 12:16 PM, lewbloch wrote: >>> The lesson I derive is that nothing is too simple, trivial or obvious >>> to overlook. >> >> >> What I got from reading that is that the root problem was that the range >> of values that the sensor was capable of producing was not understood. >> Either or both physically producing, or would produce under normal (or >> abnormal) system operation. > >As I recall, the range of values the sensor was capable of producing was >understood correctly *when the code was written*. > >The problem is that the code was written for the Ariane 4. Management >decided to re-use the same code, with no modifications, on the Ariane 5 >-- on which the valid range of values from the sensor was quite >different. > >> It was a failure to understand the the design, and its parameters. That >> failure of understanding was then propagated down to the code level. >> "We don't need to protect this because an out of range can't happen." > >Decisions had to be made when the code was written about which >exceptions to handle, and which to assume couldn't happen. >Handling them all wasn't an option because it would have slowed >down the system enough so it wouldn't work at all. The particular >decisions were correct for Ariane 4. In a sense it's not that the exception was unhandled, but rather that the exception was handled as a hardware failure, leading to the shutdown of the inertial guidance computer. Of course the backup guidance system keeled over at the same time (IIRC, the backup system may have actually tripped off first by a few ms). So the problem was not so much the unhandled exception, but the generation of the exception for the normal condition in the first place. The real head-banger is that the code in question no longer did anything useful on the Ariane 5.
[toc] | [prev] | [next] | [standalone]
| From | "io_x" <a@b.c.invalid> |
|---|---|
| Date | 2011-07-15 11:57 +0200 |
| Message-ID | <4e200eac$0$44202$4fafbaef@reader1.news.tin.it> |
| In reply to | #6197 |
"Robert Wessel" <robertwessel2@yahoo.com> ha scritto nel messaggio news:gn7v17d4ljhjsndhksgk4f1584a135u6cf@4ax.com... > On Wed, 13 Jul 2011 13:41:51 -0700, Keith Thompson <kst-u@mib.org> > wrote: > >>markspace <-@.> writes: >>> On 7/13/2011 12:16 PM, lewbloch wrote: >>>> The lesson I derive is that nothing is too simple, trivial or obvious >>>> to overlook. >>> >>> >>> What I got from reading that is that the root problem was that the range >>> of values that the sensor was capable of producing was not understood. >>> Either or both physically producing, or would produce under normal (or >>> abnormal) system operation. >> >>As I recall, the range of values the sensor was capable of producing was >>understood correctly *when the code was written*. >> >>The problem is that the code was written for the Ariane 4. Management >>decided to re-use the same code, with no modifications, on the Ariane 5 >>-- on which the valid range of values from the sensor was quite >>different. >> >>> It was a failure to understand the the design, and its parameters. That >>> failure of understanding was then propagated down to the code level. >>> "We don't need to protect this because an out of range can't happen." >> >>Decisions had to be made when the code was written about which >>exceptions to handle, and which to assume couldn't happen. >>Handling them all wasn't an option because it would have slowed >>down the system enough so it wouldn't work at all. The particular >>decisions were correct for Ariane 4. > > > In a sense it's not that the exception was unhandled, but rather that > the exception was handled as a hardware failure, leading to the > shutdown of the inertial guidance computer. Of course the backup > guidance system keeled over at the same time (IIRC, the backup system > may have actually tripped off first by a few ms). > > So the problem was not so much the unhandled exception, but the > generation of the exception for the normal condition in the first > place. > > The real head-banger is that the code in question no longer did > anything useful on the Ariane 5. if i say something if you have a prog that 'can' fail the exception that make end the program is right because this point out one error to correct; if you have a prog can not fail it is better not raise the exception
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2011-07-15 04:36 -0700 |
| Message-ID | <b6bd1f72-8241-4ff9-802f-6a047185c68c@f35g2000vbr.googlegroups.com> |
| In reply to | #6204 |
On Jul 15, 12:57 pm, "io_x" <a...@b.c.invalid> wrote: > > if i say something > if you have a prog that 'can' fail > the exception that make end the program is right > because this point out one error to correct; > > if you have a prog can not fail > it is better not raise the exception > Yes, sometimes you just have to plough on regardless, and hope that the system will recover.
[toc] | [prev] | [next] | [standalone]
| From | Niklas Holsti <niklas.holsti@tidorum.invalid> |
|---|---|
| Date | 2011-08-13 21:54 +0300 |
| Message-ID | <9anviiF606U1@mid.individual.net> |
| In reply to | #6139 |
lewbloch wrote:
> Gene Wirchenko wrote:
>> lewbloch wrote:
>>> Martin Gregorie wrote:
>> [snip]
>>
>>>> [1] The instrument causing the problem was an unmodified Ariane 4 SRI
>>>> which raised an out-of-limits exception when the normal Ariane 5
>>>> trajectory exceeded a permitted Ariane 4 horizontal velocity limit.
>> ...the Ariane 5 having more powerful engines.
>>
>>> In other words, this was a case where there *was* an out-of-range
>>> exception, thus it makes the exact opposite point to the one Gene
>>> presumably wanted to support.
>> The data I read was that the exception was not handled. IIRC,
>> debugging got interpreted as navigational data.
>>
>
> Precisely. There was an exception, and it was not handled. Having
> the exception was not enough.
There was an exception (overflow in a conversion instruction), and it
was handled. However, the handler was designed for the Ariane 4, where
the designers (after careful analysis of the data ranges for the Ariane
4) decided to assume that an overflow exception indicated a CPU HW
failure, and consequently the handler shut down the CPU. The same
overflow then occurred in the redundant CPU, which also shut down, so
the rocket was left with no guidance.
If the SW had been tested properly, the overflow exception would have
occurred during testing, which would have revealed the flawed
assumptions made in the reuse of the Ariane 4 SW on the Ariane 5. Surely
that would have been better than ignoring the overflow.
The Ariane 501 disaster is a poor guide for this discussion, because of
the difficulty of proper exception handling in that system: you cannot
abort the launch and return to the launch pad. In most applications, it
is much easier to design reasonable and safe exception handlers.
--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
[toc] | [prev] | [next] | [standalone]
| From | tm <thomas.mertes@gmx.at> |
|---|---|
| Date | 2011-07-13 00:52 -0700 |
| Message-ID | <e0f4f6a1-9bcd-4475-8277-abb427d6b99d@v12g2000vby.googlegroups.com> |
| In reply to | #6105 |
On 13 Jul., 05:03, "Greg A. Woods" <wo...@robohack.org> wrote: > tm <thomas.mer...@gmx.at> writes: > > > Yes, but it must be checked after every operation. > > A hardware that triggers an interrupt, would save this > > extra checks. > > I think you're assuming either the code is running nearly bare on the > hardware (in which case your program has its own ISR), or that your OS > has a very inexpensive way to deliver the ISR to a process. I was not talking about the overhead that occurs when an overflow happens. Exceptions should be rare and people know that they are not as cheap as normal computations. I thought about overhead, when NO overflow occurs. In an ideal world code with and without overflow checking would run at the same speed (as long as no overflow occurs). > As I mentioned in another post just now, a decent compiler can use > library routines for all arithmetic operations and thus allow all > operations to be checked for overflow algorithmically. Yes, but this would have probable more overhead than checking an overflow flag, not to mention hardware that can do this without extra cost (trigger interrupt). > See GCC's "-ftrapv" option, for example. AFAIK -ftrapv adds code to check an overflow flag after arithmetic operations. IMHO -ftrapv is the right way, because it allows gcc to use hardware support (when a CPU is able to trigger an interrupt on overflow). BTW, does gcj support this option also? Has javac a similar option? > You may also be assuming that overflows aren't so common in C. :-) > > Try re-compiling your system's entire userland with "gcc -ftrapv" and > see how much of it still works without aborting. It does work. I just had to change a program which checks left shift by comparing the result with a multiplication by a power of two. AFAIK left shift is not checked by -ftrapv, but multiplication is. Nor the chkint.sd7 program only checks left shift in situations where no overflow occurs. Using the signal to raise an exception is something else. E.g.: gcc and clang disagree in the signal used (gcc: SIGABRT, clang: SIGILL). So useful support of this feature in Seed7 may take some time. 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 | Patricia Shanahan <pats@acm.org> |
|---|---|
| Date | 2011-07-13 07:45 -0700 |
| Message-ID | <o_mdnVK37_QeMoDTnZ2dnUVZ_hSdnZ2d@earthlink.com> |
| In reply to | #6154 |
On 7/13/2011 12:52 AM, tm wrote: > On 13 Jul., 05:03, "Greg A. Woods"<wo...@robohack.org> wrote: ... >> As I mentioned in another post just now, a decent compiler can use >> library routines for all arithmetic operations and thus allow all >> operations to be checked for overflow algorithmically. > > Yes, but this would have probable more overhead than checking > an overflow flag, not to mention hardware that can do this > without extra cost (trigger interrupt). I'm not convinced that there would be extra cost. The main performance costs on modern processors tend to be data movement, and mis-predicted conditional branches. The overflow check needs no additional data, and the associated conditional branches will be about as easy to predict as is possible. Patricia
[toc] | [prev] | [next] | [standalone]
| From | Wolfgang Draxinger <wdraxinger@darkstargames.de> |
|---|---|
| Date | 2011-09-08 21:02 +0200 |
| Message-ID | <20110908210243.710b9d01@loki.yggdrasil.draxit.de> |
| In reply to | #6029 |
Am Sun, 10 Jul 2011 01:47:25 -0700 (PDT) schrieb tm <thomas.mertes@gmx.at>: > A CPU could (in theory) easily recognize the overflow > and generate an interrupt. This way normal computations > (without overflow) would have no extra cost. Interrupts are extremely expensive. They require the OS kernel into a full blown context switch, registers must be saved and restored. And finally the process needs to be signaled. Nobody sane in his mind would it be done that way. > AFAIK commonly used CPUs do not have this possibility. They > have some FLAG, which is set when an overflow occurred. And checking a flag is how difficult? It's a simple, cheap conditional jump. And the execution prediction system works very efficient on flags, because they're integral CPU state. > 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. So? Checks are not expensive. Heck, some architectures, like ARM, execute instructions conditionally, depending on a flag. Reacting on a overflow flag comes with NO EXTRA COST there. > Needless to say: Normal computations (without overflow) > are slowed down by this checks. No, they are not. Modern pipelined CPUs have codepath prediction and out-of-order-operations, where some codepaths are executed proactively and their results are kept on-hold. The instructions reacting upon the overflow flag check may have been finished, even before the offending operation may have been. > Because of this slow down most compilers and virtual > machines (AFAIK inluding the JVM) have no overflow > checking. Almost every new language designed implement overflow checks. Also every generic container library does so. Overflow checks cost NOTHING these days. > In other words: A missing hardware feature: > > Trigger interupt when overflow flag is set. > > Causes compilers and JVMs to omit overflow checks. Did you ever think about the kind of infrastructure that's required for this? This goes down into the bowels of the OS kernel. Interrupts always cause context switches, which are expensive. Checking a flag comes practically for free. Especially if the execution prediction can determine, that a certain codepath depends on a certain flag only. To give you some figures: Processing an interrupt takes Linux about 1 to 10µs. On a 3GHz CPU that amounts to 30000 clockcycles, and most modern, pipelined CPUs finish at least 1 instruction per clock cycle; on a Intel Pentium or Core for the majority of instructions have a up to 8 finished instructions per clock cycle. In the time your proposed overflow-check interrupt is processed you can do about 200000 flag checks. Wolfgang
[toc] | [prev] | [next] | [standalone]
| From | Wolfgang Draxinger <wdraxinger@darkstargames.de> |
|---|---|
| Date | 2011-09-08 21:12 +0200 |
| Message-ID | <20110908211243.7932aa0c@loki.yggdrasil.draxit.de> |
| In reply to | #7709 |
Am Thu, 8 Sep 2011 21:02:43 +0200 schrieb Wolfgang Draxinger <wdraxinger@darkstargames.de>: > To give you some figures: Processing an interrupt takes Linux about 1 > to 10µs. On a 3GHz CPU that amounts to 30000 clockcycles, and most > modern, pipelined CPUs finish at least 1 instruction per clock cycle; > on a Intel Pentium or Core for the majority of instructions have a up > to 8 finished instructions per clock cycle. In the time your proposed > overflow-check interrupt is processed you can do about 200000 flag > checks. Well, I was off by a factor of ~10. The typical Linux ISR takes about 2000 clock cycles. Still going such a long way is still a lot slower than checking the flag in under a cycle. Wolfgang
[toc] | [prev] | [next] | [standalone]
| From | Willem <willem@toad.stack.nl> |
|---|---|
| Date | 2011-09-08 19:15 +0000 |
| Message-ID | <slrnj6i521.1t7i.willem@toad.stack.nl> |
| In reply to | #7711 |
Wolfgang Draxinger wrote:
) Am Thu, 8 Sep 2011 21:02:43 +0200
) schrieb Wolfgang Draxinger <wdraxinger@darkstargames.de>:
)
)> To give you some figures: Processing an interrupt takes Linux about 1
)> to 10??s. On a 3GHz CPU that amounts to 30000 clockcycles, and most
)> modern, pipelined CPUs finish at least 1 instruction per clock cycle;
)> on a Intel Pentium or Core for the majority of instructions have a up
)> to 8 finished instructions per clock cycle. In the time your proposed
)> overflow-check interrupt is processed you can do about 200000 flag
)> checks.
)
) Well, I was off by a factor of ~10. The typical Linux ISR takes about
) 2000 clock cycles. Still going such a long way is still a lot slower
) than checking the flag in under a cycle.
So if an overflow condition typically occurs less than 1 in 10000 times,
the interrupt solution is better.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
[toc] | [prev] | [next] | [standalone]
| From | Wolfgang Draxinger <wdraxinger@darkstargames.de> |
|---|---|
| Date | 2011-09-08 22:24 +0200 |
| Message-ID | <20110908222442.3eda3e88@loki.yggdrasil.draxit.de> |
| In reply to | #7712 |
Am Thu, 8 Sep 2011 19:15:13 +0000 (UTC) schrieb Willem <willem@toad.stack.nl>: > So if an overflow condition typically occurs less than 1 in 10000 > times, the interrupt solution is better. Theoretically yes, practically no! It depends on the architecture. On ARM it doesn't matter at all, since ALL instructions are conditional. On x86 architecture due to pipelining and OOE the differences are not measureable as well (the overflow case code executes in parallel and may have been finished, before the code, creating the overflow executed at all). Also the overflow condition will probably not do any arithmetic, in contrast to the arithmetic that does overflow. So these are separate functional units at work, so pipelining will execute them in parallel. Really, there no cost to speak of in doing overflow checks. Wolfgang
[toc] | [prev] | [next] | [standalone]
Page 5 of 14 — ← Prev page 1 … 3 4 [5] 6 7 … 14 Next page →
Back to top | Article view | comp.lang.java.programmer
csiph-web