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 11 of 14 — ← Prev page 1 … 9 10 [11] 12 13 14 Next page →
| From | Eric Sosman <esosman@ieee-dot-org.invalid> |
|---|---|
| Date | 2011-07-07 07:54 -0400 |
| Message-ID | <iv46rb$8vg$1@dont-email.me> |
| In reply to | #5958 |
On 7/7/2011 3:30 AM, rop rop wrote:
> On Jul 6, 11:32 pm, Tom Anderson<t...@urchin.earth.li> wrote:
>> Modding the JVM is a non-starter for a few reasons...
>
> Hi Tom,
> Thanks for input.
> Could you just elaborate on this, please... what is the main-problem
> with actually patching the JVM?
> Why is it so hard?
> Without having looked into the source-code, this seems like the most
> straight-forward and robust way to do it...
> Is the code so hard to penetrate or what?
The first thing that comes to mind is altering a JVM so it does
not behave as described in the Java Virtual Machine Specification
means you no longer have a JVM. Specifically, from section 2.4.2:
"The built-in integer operators do not indicate (positive or negative)
overflow in any way; they wrap around on overflow." For good or for
ill, that's a requirement all JVM implementations must satisfy.
But, okay, you start with a JVM and alter it to produce a "KWN"
that behaves just like a JVM except in this one regard. Now a second
difficulty arises: You start running Java on the KWN, and almost at
once you get an arithmetic overflow exception. Investigating, you
find that it occurred in a hashCode() method that's computing the
time-honored sum x0+p*(x1+p*(x2+...)) with the fields x0,x1,... and
a prime p. The overflow is entirely benign, yet "Hello".hashCode()
stops your program in its tracks. So now you need a way to distinguish
expected (benign) overflow from unanticipated (injurious) overflow --
which means you need to alter not only the JVM but also Java. (Or maybe
you could do something with annotations; I'm not sure.) But the main
point is that all existing Java code expects overflow to wrap around,
and lots of that code actually relies on wraparound.
Finally, you've got definitional problems to sort out. For
example, is there an overflow in `int value = (int)Long.LONG_MAX;'?
You need to put on your Language Legislator hat and think about it
before you can decide how your KWN should behave.
Personally, I wish integer over- and under-flow would in fact
throw exceptions, and that the language had something like `unsigned'
to allow the programmer to suppress the exceptions when appropriate.
But that's a wish I don't expect to see fulfilled.
--
Eric Sosman
esosman@ieee-dot-org.invalid
[toc] | [prev] | [next] | [standalone]
| From | rop rop <rop049@gmail.com> |
|---|---|
| Date | 2011-07-07 05:36 -0700 |
| Message-ID | <8c57ec72-679f-42e0-81ac-8526ff9ca1bb@v10g2000yqn.googlegroups.com> |
| In reply to | #5961 |
On Jul 7, 1:54 pm, Eric Sosman <esos...@ieee-dot-org.invalid> wrote: > On 7/7/2011 3:30 AM, rop rop wrote: > > > On Jul 6, 11:32 pm, Tom Anderson<t...@urchin.earth.li> wrote: > >> Modding the JVM is a non-starter for a few reasons... > > > Hi Tom, > > Thanks for input. > > Could you just elaborate on this, please... what is the main-problem > > with actually patching the JVM? > > Why is it so hard? > > Without having looked into the source-code, this seems like the most > > straight-forward and robust way to do it... > > Is the code so hard to penetrate or what? > > The first thing that comes to mind is altering a JVM so it does > not behave as described in the Java Virtual Machine Specification > means you no longer have a JVM. Specifically, from section 2.4.2: > "The built-in integer operators do not indicate (positive or negative) > overflow in any way; they wrap around on overflow." For good or for > ill, that's a requirement all JVM implementations must satisfy. > > But, okay, you start with a JVM and alter it to produce a "KWN" > that behaves just like a JVM except in this one regard. Now a second > difficulty arises: You start running Java on the KWN, and almost at > once you get an arithmetic overflow exception. Investigating, you > find that it occurred in a hashCode() method that's computing the > time-honored sum x0+p*(x1+p*(x2+...)) with the fields x0,x1,... and > a prime p. The overflow is entirely benign, yet "Hello".hashCode() > stops your program in its tracks. So now you need a way to distinguish > expected (benign) overflow from unanticipated (injurious) overflow -- > which means you need to alter not only the JVM but also Java. (Or maybe > you could do something with annotations; I'm not sure.) But the main > point is that all existing Java code expects overflow to wrap around, > and lots of that code actually relies on wraparound. > > Finally, you've got definitional problems to sort out. For > example, is there an overflow in `int value = (int)Long.LONG_MAX;'? > You need to put on your Language Legislator hat and think about it > before you can decide how your KWN should behave. > > Personally, I wish integer over- and under-flow would in fact > throw exceptions, and that the language had something like `unsigned' > to allow the programmer to suppress the exceptions when appropriate. > But that's a wish I don't expect to see fulfilled. > > -- > Eric Sosman > esos...@ieee-dot-org.invalid Thanks for clarification Eric -- besides no longer being a "JVM" (which I am aware of and dont care abt here), I now start to see the technical problems :) So one would also need a way to specify what classes overflow-checking should apply to, either a class-annotation, or perhaps a runtime-flag -Xcheckforoverflow.classes=my.firstpkg.*;my.secondpkg.* or similar would be practical.
[toc] | [prev] | [next] | [standalone]
| From | Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> |
|---|---|
| Date | 2011-07-07 19:11 +0200 |
| Message-ID | <iv4pc9$ip$1@dont-email.me> |
| In reply to | #5961 |
On 07/07/2011 13:54, Eric Sosman allegedly wrote: > On 7/7/2011 3:30 AM, rop rop wrote: >> On Jul 6, 11:32 pm, Tom Anderson<t...@urchin.earth.li> wrote: >>> Modding the JVM is a non-starter for a few reasons... >> >> Hi Tom, >> Thanks for input. >> Could you just elaborate on this, please... what is the main-problem >> with actually patching the JVM? >> Why is it so hard? >> Without having looked into the source-code, this seems like the most >> straight-forward and robust way to do it... >> Is the code so hard to penetrate or what? > > The first thing that comes to mind is altering a JVM so it does > not behave as described in the Java Virtual Machine Specification > means you no longer have a JVM. Specifically, from section 2.4.2: > "The built-in integer operators do not indicate (positive or negative) > overflow in any way; they wrap around on overflow." For good or for > ill, that's a requirement all JVM implementations must satisfy. > > But, okay, you start with a JVM and alter it to produce a "KWN" > that behaves just like a JVM except in this one regard. Now a second > difficulty arises: You start running Java on the KWN, and almost at > once you get an arithmetic overflow exception. Investigating, you > find that it occurred in a hashCode() method that's computing the > time-honored sum x0+p*(x1+p*(x2+...)) with the fields x0,x1,... and > a prime p. The overflow is entirely benign, yet "Hello".hashCode() > stops your program in its tracks. So now you need a way to distinguish > expected (benign) overflow from unanticipated (injurious) overflow -- > which means you need to alter not only the JVM but also Java. (Or maybe > you could do something with annotations; I'm not sure.) But the main > point is that all existing Java code expects overflow to wrap around, > and lots of that code actually relies on wraparound. > > Finally, you've got definitional problems to sort out. For > example, is there an overflow in `int value = (int)Long.LONG_MAX;'? > You need to put on your Language Legislator hat and think about it > before you can decide how your KWN should behave. > > Personally, I wish integer over- and under-flow would in fact > throw exceptions, and that the language had something like `unsigned' > to allow the programmer to suppress the exceptions when appropriate. > But that's a wish I don't expect to see fulfilled. > Not to mention the mess if it's an app you plan to distribute. -- DF. Determinism trumps correctness.
[toc] | [prev] | [next] | [standalone]
| From | Tom Anderson <twic@urchin.earth.li> |
|---|---|
| Date | 2011-07-07 14:21 +0100 |
| Message-ID | <alpine.DEB.2.00.1107071405430.17342@urchin.earth.li> |
| In reply to | #5958 |
[Multipart message — attachments visible in raw view] — view raw
On Thu, 7 Jul 2011, rop rop wrote: > On Jul 6, 11:32 pm, Tom Anderson <t...@urchin.earth.li> wrote: >> Modding the JVM is a non-starter for a few reasons... > > Could you just elaborate on this, please... what is the main-problem > with actually patching the JVM? Why is it so hard? It would involve modifying a bytecode interpreter and two just-in-time compilers, all three highly developed instances of their species, and all written in C++. How much do you know about interpreters and compilers, and how is your C++? I am a good Java programmer, but that task would be way beyond me. > Without having looked into the source-code, this seems like the most > straight-forward and robust way to do it... Prefixing a statement about some source code with 'without having looked at the source-code' pretty much disqualifies it completely. Tell you what: the source code to the x86 version of HotSpot is here: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/file/tip/src/cpu/x86/vm/ In particular, here's the table of assembly instructions used for each bytecode in the interpreter: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/file/tip/src/cpu/x86/vm/templateTable_x86_32.cpp Have a look at that, and let me know how hard you think it would be to modify that to do overflow checking (and remember that you can't do it everywhere, because existing code is written to use overflow - you have to have some way of only doing it in specified bits of code). tom -- Links are content.
[toc] | [prev] | [next] | [standalone]
| From | Stanimir Stamenkov <s7an10@netscape.net> |
|---|---|
| Date | 2011-07-09 16:34 +0300 |
| Message-ID | <iv9ld6$qnr$1@dont-email.me> |
| In reply to | #5925 |
Wed, 6 Jul 2011 22:28:50 +0200, /Tom Anderson/: > using a library or a set of functions by convention is error-prone, The set of library functions would just address the requirement of not cluttering the code. The error-proneness is usually addressed by writing appropriate unit tests which verify the code is dealing with overflow situations in expected manner. -- Stanimir
[toc] | [prev] | [next] | [standalone]
| From | Roedy Green <see_website@mindprod.com.invalid> |
|---|---|
| Date | 2011-07-06 22:41 -0700 |
| Message-ID | <knha175c4hu8491pmmek09thqmo7niq3s2@4ax.com> |
| In reply to | #5905 |
On Wed, 6 Jul 2011 08:35:01 -0700 (PDT), rop rop <rop049@gmail.com> wrote, quoted or indirectly quoted someone who said : >If I want to have arithmetic-overflow checking in all parts of an >application, >what is the most practical, simple, efficient way to achieve this? >Id like to clutter the code as little a possible... >Is there any way to instruct the JVM to include it? the JVM does not detect it because most hardware does not. You pretty well have to use long instead of int and mask off and check overflow. -- Roedy Green Canadian Mind Products http://mindprod.com One thing I love about having a website, is that when I complain about something, I only have to do it once. It saves me endless hours of grumbling.
[toc] | [prev] | [next] | [standalone]
| From | Gene Wirchenko <genew@ocis.net> |
|---|---|
| Date | 2011-07-07 14:34 -0700 |
| Message-ID | <1f9c17dltrhlmhifuigoa914477r4rg1e1@4ax.com> |
| In reply to | #5954 |
On Wed, 06 Jul 2011 22:41:54 -0700, Roedy Green
<see_website@mindprod.com.invalid> wrote:
>On Wed, 6 Jul 2011 08:35:01 -0700 (PDT), rop rop <rop049@gmail.com>
>wrote, quoted or indirectly quoted someone who said :
>
>>If I want to have arithmetic-overflow checking in all parts of an
>>application,
>>what is the most practical, simple, efficient way to achieve this?
>>Id like to clutter the code as little a possible...
>>Is there any way to instruct the JVM to include it?
>
>the JVM does not detect it because most hardware does not. You pretty
>well have to use long instead of int and mask off and check overflow.
Which hardware does not have overflow detection?
x86 does have an overflow flag.
Sincerely,
Gene Wirchenko
[toc] | [prev] | [next] | [standalone]
| From | Patricia Shanahan <pats@acm.org> |
|---|---|
| Date | 2011-07-07 14:53 -0700 |
| Message-ID | <l_qdnfmZ-4tpt4vTnZ2dnUVZ_sqdnZ2d@earthlink.com> |
| In reply to | #5971 |
On 7/7/2011 2:34 PM, Gene Wirchenko wrote: > On Wed, 06 Jul 2011 22:41:54 -0700, Roedy Green > <see_website@mindprod.com.invalid> wrote: > >> On Wed, 6 Jul 2011 08:35:01 -0700 (PDT), rop rop<rop049@gmail.com> >> wrote, quoted or indirectly quoted someone who said : >> >>> If I want to have arithmetic-overflow checking in all parts of an >>> application, >>> what is the most practical, simple, efficient way to achieve this? >>> Id like to clutter the code as little a possible... >>> Is there any way to instruct the JVM to include it? >> >> the JVM does not detect it because most hardware does not. You pretty >> well have to use long instead of int and mask off and check overflow. > > Which hardware does not have overflow detection? > > x86 does have an overflow flag. So far, every instruction set I have studied has included overflow detection at the hardware level. I think the problem is more a matter of software knowing when overflow should and should not be treated as an error. Patricia
[toc] | [prev] | [next] | [standalone]
| From | Gene Wirchenko <genew@ocis.net> |
|---|---|
| Date | 2011-07-07 17:12 -0700 |
| Message-ID | <koic171t5gas91890r8l9914v26snm7k1v@4ax.com> |
| In reply to | #5973 |
On Thu, 07 Jul 2011 14:53:50 -0700, Patricia Shanahan <pats@acm.org>
wrote:
[snip]
>I think the problem is more a matter of software knowing when overflow
>should and should not be treated as an error.
Exactly. C does not do that sort of checking, and the meme has
spread widely. I would much prefer to have things blow up when wrong
than not blow up. It makes for smaller messes.
Sincerely,
Gene Wirchenko
[toc] | [prev] | [next] | [standalone]
| From | lewbloch <lewbloch@gmail.com> |
|---|---|
| Date | 2011-07-07 17:29 -0700 |
| Message-ID | <b3d4a08b-3428-442a-8cce-30edc2868a47@5g2000yqb.googlegroups.com> |
| In reply to | #5974 |
On Jul 7, 5:12 pm, Gene Wirchenko <ge...@ocis.net> wrote: > On Thu, 07 Jul 2011 14:53:50 -0700, Patricia Shanahan <p...@acm.org> > wrote: > > [snip] > > >I think the problem is more a matter of software knowing when overflow > >should and should not be treated as an error. > > Exactly. C does not do that sort of checking, and the meme has > spread widely. I would much prefer to have things blow up when wrong > than not blow up. It makes for smaller messes. > the problem with that statement is that it's not wrong for Java primitive integer types to wrap around. It is, in fact, wrong for them to throw an overflow exception, as many have pointed out in this thread. -- Lew
[toc] | [prev] | [next] | [standalone]
| From | Gene Wirchenko <genew@ocis.net> |
|---|---|
| Date | 2011-07-08 10:27 -0700 |
| Message-ID | <09fe171s46ilvq9qmn254dctunm6noh0ps@4ax.com> |
| In reply to | #5975 |
On Thu, 7 Jul 2011 17:29:42 -0700 (PDT), lewbloch <lewbloch@gmail.com>
wrote:
>On Jul 7, 5:12 pm, Gene Wirchenko <ge...@ocis.net> wrote:
>> On Thu, 07 Jul 2011 14:53:50 -0700, Patricia Shanahan <p...@acm.org>
>> wrote:
>>
>> [snip]
>>
>> >I think the problem is more a matter of software knowing when overflow
>> >should and should not be treated as an error.
>>
>> Exactly. C does not do that sort of checking, and the meme has
>> spread widely. I would much prefer to have things blow up when wrong
>> than not blow up. It makes for smaller messes.
>>
>
>the problem with that statement is that it's not wrong for Java
>primitive integer types to wrap around.
Java is designed to behave that way. That does not mean that it
is not wrong.
A garrot is designed to be a murder weapon. That it was designed
for that does not make any murder committed with a garrot any less
wrong.
>It is, in fact, wrong for them to throw an overflow exception, as many
>have pointed out in this thread.
It is designed to behave like that. That behaviour is often
wrong from the point of view of ensuring program correctness.
C allows wraparound with unsigned (which I wish Java had)
integers. An overflow with signed integers results in undefined
behaviour. C's semantics are better than those of Java in this
regard. They should be better: throw an error.
Sincerely,
Gene Wrichenko
[toc] | [prev] | [next] | [standalone]
| From | lewbloch <lewbloch@gmail.com> |
|---|---|
| Date | 2011-07-08 13:15 -0700 |
| Message-ID | <f6ed8d08-bc7a-43e4-aecf-878511705353@j15g2000yqf.googlegroups.com> |
| In reply to | #5990 |
On Jul 8, 10:27 am, Gene Wirchenko <ge...@ocis.net> wrote: > On Thu, 7 Jul 2011 17:29:42 -0700 (PDT), lewbloch <lewbl...@gmail.com> > wrote: > > > > > > > > > > >On Jul 7, 5:12 pm, Gene Wirchenko <ge...@ocis.net> wrote: > >> On Thu, 07 Jul 2011 14:53:50 -0700, Patricia Shanahan <p...@acm.org> > >> wrote: > > >> [snip] > > >> >I think the problem is more a matter of software knowing when overflow > >> >should and should not be treated as an error. > > >> Exactly. C does not do that sort of checking, and the meme has > >> spread widely. I would much prefer to have things blow up when wrong > >> than not blow up. It makes for smaller messes. > > >the problem with that statement is that it's not wrong for Java > >primitive integer types to wrap around. > > Java is designed to behave that way. That does not mean that it > is not wrong. > It doesn't mean that it is wrong. In fact, it does mean that it's not wrong. If you're working in Java, to do differently from what the Java spec requires is wrong. As others have pointed out, there's an awful lot of code that depends on the documented, required behavior. For that code, to have overflow exceptions would be wrong, doubly so because it would violate the rules under which the code was developed. > A garrot is designed to be a murder weapon. That it was designed > for that does not make any murder committed with a garrot any less > wrong. > A useless analogy that adds no insight to the question of overflow exceptions. There is no evidence that wrapping around overflow is equivalent to a murder weapon other than your fanciful rhetoric. > >It is, in fact, wrong for them to throw an overflow exception, as many > >have pointed out in this thread. > > It is designed to behave like that. That behaviour is often > wrong from the point of view of ensuring program correctness. > Much more often, in Java, the behavior is right from the point of view of ensuring program correctness, because Java programs are written with the required behavior in mind. > C allows wraparound with unsigned (which I wish Java had) > integers. An overflow with signed integers results in undefined > behaviour. C's semantics are better than those of Java in this > regard. They should be better: throw an error. > "should" is pretty useless here - Java should do what it's documented to do. There are programmatic workarounds for preventing wraparound, and no doubt there are errors that arise from the lack of overflow exception trapping, just as there would be errors possible from its presence. You have a personal preference to trap overflow exceptions, which you like to present as an absolute rule for all programmers. that doesn't make your personal preference better, just yours. You've offered no objective evidence that your preference would be better for anyone besides yourself; others here have offered evidence that to change Java's behavior would cause more errors than your idea would fix. I fully support your right to have a personal preference. -- Lew
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2011-07-19 20:54 -0400 |
| Message-ID | <4e262731$0$314$14726298@news.sunsite.dk> |
| In reply to | #5996 |
On 7/8/2011 4:15 PM, lewbloch wrote: > On Jul 8, 10:27 am, Gene Wirchenko<ge...@ocis.net> wrote: >> On Thu, 7 Jul 2011 17:29:42 -0700 (PDT), lewbloch<lewbl...@gmail.com> >> wrote: >>> On Jul 7, 5:12 pm, Gene Wirchenko<ge...@ocis.net> wrote: >>>> On Thu, 07 Jul 2011 14:53:50 -0700, Patricia Shanahan<p...@acm.org> >>>> wrote: >>>>> I think the problem is more a matter of software knowing when overflow >>>>> should and should not be treated as an error. >> >>>> Exactly. C does not do that sort of checking, and the meme has >>>> spread widely. I would much prefer to have things blow up when wrong >>>> than not blow up. It makes for smaller messes. >> >>> the problem with that statement is that it's not wrong for Java >>> primitive integer types to wrap around. >> >> Java is designed to behave that way. That does not mean that it >> is not wrong. > > It doesn't mean that it is wrong. > > In fact, it does mean that it's not wrong. If you're working in Java, > to do differently from what the Java spec requires is wrong. > > As others have pointed out, there's an awful lot of code that depends > on the documented, required behavior. For that code, to have overflow > exceptions would be wrong, doubly so because it would violate the > rules under which the code was developed. Yes, but given that there are already two languages under discussion, then it seems rather obvious that his point is that Java should have been designed different 16 years ago not change overflow handling in Java 8. Arne
[toc] | [prev] | [next] | [standalone]
| From | markspace <-@.> |
|---|---|
| Date | 2011-07-19 18:07 -0700 |
| Message-ID | <j059o8$684$1@dont-email.me> |
| In reply to | #6294 |
On 7/19/2011 5:54 PM, Arne Vajhøj wrote: >> On Jul 8, 10:27 am, Gene Wirchenko<ge...@ocis.net> wrote: >>> Java is designed to behave that way. That does not mean that it >>> is not wrong. > On 7/8/2011 4:15 PM, lewbloch wrote: >> >> It doesn't mean that it is wrong. >> > Yes, but given that there are already two languages under discussion, > then it seems rather obvious that his point is that Java should have > been designed different 16 years ago not change overflow handling > in Java 8. I think the point being made is that it's behavior that could be improved *now*. The prescience required to see 16 years into the future is darn hard. I don't think anyone at all has that kind of skill or knowledge. It would have been better however to acknowledge sometime in the past that Java needed to be improved in some fundamental ways and then make those changes. Generics should have been reifiable, primitives should be "first class objects," integer math should be checked for overflow where the programmer deems needed. These things have been lacking for some time, and are still needed, imo.
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2011-07-19 21:31 -0400 |
| Message-ID | <4e26300b$0$309$14726298@news.sunsite.dk> |
| In reply to | #6296 |
On 7/19/2011 9:07 PM, markspace wrote: > On 7/19/2011 5:54 PM, Arne Vajhøj wrote: >>> On Jul 8, 10:27 am, Gene Wirchenko<ge...@ocis.net> wrote: >>>> Java is designed to behave that way. That does not mean that it >>>> is not wrong. > > > On 7/8/2011 4:15 PM, lewbloch wrote: >>> >>> It doesn't mean that it is wrong. >>> > >> Yes, but given that there are already two languages under discussion, >> then it seems rather obvious that his point is that Java should have >> been designed different 16 years ago not change overflow handling >> in Java 8. > > > I think the point being made is that it's behavior that could be > improved *now*. > > The prescience required to see 16 years into the future is darn hard. I > don't think anyone at all has that kind of skill or knowledge. It would > have been better however to acknowledge sometime in the past that Java > needed to be improved in some fundamental ways and then make those changes. > > Generics should have been reifiable, primitives should be "first class > objects," integer math should be checked for overflow where the > programmer deems needed. These things have been lacking for some time, > and are still needed, imo. Today it is a must that changes must not break existing code. That still leaves some room for improvements. But it tend to become messy. Sometimes we just need to realize that a wrong decision was made, that we are stuck with it and that it should be done correctly in the next language. Arne
[toc] | [prev] | [next] | [standalone]
| From | Arved Sandstrom <asandstrom3minus1@eastlink.ca> |
|---|---|
| Date | 2011-07-20 07:36 -0300 |
| Message-ID | <cdyVp.5929$Vn5.2217@newsfe18.iad> |
| In reply to | #6297 |
On 11-07-19 10:31 PM, Arne Vajhøj wrote: > On 7/19/2011 9:07 PM, markspace wrote: >> On 7/19/2011 5:54 PM, Arne Vajhøj wrote: >>>> On Jul 8, 10:27 am, Gene Wirchenko<ge...@ocis.net> wrote: >>>>> Java is designed to behave that way. That does not mean that it >>>>> is not wrong. >> >> > On 7/8/2011 4:15 PM, lewbloch wrote: >>>> >>>> It doesn't mean that it is wrong. >>>> >> >>> Yes, but given that there are already two languages under discussion, >>> then it seems rather obvious that his point is that Java should have >>> been designed different 16 years ago not change overflow handling >>> in Java 8. >> >> >> I think the point being made is that it's behavior that could be >> improved *now*. >> >> The prescience required to see 16 years into the future is darn hard. I >> don't think anyone at all has that kind of skill or knowledge. It would >> have been better however to acknowledge sometime in the past that Java >> needed to be improved in some fundamental ways and then make those >> changes. >> >> Generics should have been reifiable, primitives should be "first class >> objects," integer math should be checked for overflow where the >> programmer deems needed. These things have been lacking for some time, >> and are still needed, imo. > > Today it is a must that changes must not break existing code. > > That still leaves some room for improvements. > > But it tend to become messy. > > Sometimes we just need to realize that a wrong decision was > made, that we are stuck with it and that it should be done > correctly in the next language. > > Arne > Changes, even backwards-incompatible changes, to version X of a language do not break existing code *unless* users of that existing code make a conscious choice to operate that code in the new environment. I am not convinced there is a strong need to do that. As an example, and I'm sure I'm not alone in this, I routinely maintain applications in 2011 that are J2EE 1.4 or Java EE 5. No shortage of them are J2EE 1.4. Some colleagues who maintain other big web apps I am familiar with have to deal with Struts 1. The penetration of Java EE 6 applications and Java EE 6 servers into the local big business and government scene is paltry. In terms of the associated Java versions, it's true that many folks use Java 5 or 6 (frequently 1.6 latest update) even if they are developing for a J2EE 1.4 server, but in my experience there has rarely been a compelling need for it. To put it another way, I have little time for someone who argues that they just absolutely need a cool Java 6 language feature but they can't be bothered to upgrade from J2EE 1.4. Looking at the Oracle support roadmaps for J2SE/Java SE, fact is that J2SE 1.4, and Java 5/6, will have some form of adequate support for a long time yet (http://www.oracle.com/technetwork/java/eol-135779.html). If Java 8, for example, decided to make some backwards-incompatible changes to the language, people with existing code bases would have sufficient options with Java 7 or earlier to keep them happy for a long, long time. I simply do not see the validity of an argument that says that the existence of an incompatible Java 8 or 9 is going to affect any of these people. As it is, I expect not to be primarily working with Java EE 6 and JDK 7 until 2015 at the earliest...and that may be optimistic for the Java EE side of things. As far as "next" languages go, we've already been getting them on the JVM: Scala and Clojure for example. Or you just abandon the JVM entirely. Holding back from certain language changes just so someone can compile a codebase written against Java 5 on a Java 9 compiler, and have it work, is holding back the entire language. Ironically, the conservative users that we are pandering to with this approach wouldn't be in any hurry to use the latest JDK anyway...if ever. And the hard-charging bleeding-edge developers can certainly rewrite some existing code in the midst of using all the new features and APIs. AHS
[toc] | [prev] | [next] | [standalone]
| From | RedGrittyBrick <RedGrittyBrick@spamweary.invalid> |
|---|---|
| Date | 2011-07-20 11:58 +0100 |
| Message-ID | <4e26b4ed$0$2501$db0fefd9@news.zen.co.uk> |
| In reply to | #6302 |
On 20/07/2011 11:36, Arved Sandstrom wrote: > Holding back from certain language changes just so someone can > compile a codebase written against Java 5 on a Java 9 compiler, and have > it work, is holding back the entire language. Why is this a problem? Firstly, you can use `javac -source 1.3` to compile old code, can't you? Secondly, a future version of Java could introduce some mechanism such as in-line compiler directives that turn new compiler-behaviours/language-features on for specified classes or for specified sections of code (I'm thinking of Perl's `use feature` pragma but I'm sure this sort of idea exists in other languages). -- RGB
[toc] | [prev] | [next] | [standalone]
| From | lewbloch <lewbloch@gmail.com> |
|---|---|
| Date | 2011-07-20 09:51 -0700 |
| Message-ID | <f126e0ad-e1e5-47c8-949e-e38b3598d5ff@m5g2000prh.googlegroups.com> |
| In reply to | #6303 |
RedGrittyBrick <RedGrittyBr...@spamweary.invalid> wrote: > Arved Sandstrom wrote: >> Holding back from certain language changes just so someone can >> compile a codebase written against Java 5 on a Java 9 compiler, and have >> it work, is holding back the entire language. > > Why is this a problem? > > Firstly, you can use `javac -source 1.3` to compile old code, can't you? > No. Not if you want some of the new features. For example, if you're developing to Java 6 and want to keep generics but don't want autoboxing, you cannot use '-source 1.3 -target 1.3'. So, if you have a library that breaks with Java 5 or later, such as commons-lang enumerations under rare situations, you cannot accommodate that simply by 'source 1.4'ing it without giving up other desirable features. You also have to make sure that all your third-party libraries for that build conform to the older spec. Targeting an old version is an all-or-nothing proposition. > Secondly, a future version of Java could introduce some mechanism such > as in-line compiler directives that turn new > compiler-behaviours/language-features on for specified classes or for > specified sections of code (I'm thinking of Perl's `use feature` pragma > but I'm sure this sort of idea exists in other languages). > It'll come down to someone's perception of how valuable that feature is against the cost. -- Lew
[toc] | [prev] | [next] | [standalone]
| From | RedGrittyBrick <RedGrittyBrick@spamweary.invalid> |
|---|---|
| Date | 2011-07-21 12:11 +0100 |
| Message-ID | <4e28097f$0$2533$da0feed9@news.zen.co.uk> |
| In reply to | #6311 |
On 20/07/2011 17:51, lewbloch wrote:
> RedGrittyBrick<RedGrittyBr...@spamweary.invalid> wrote:
>> Arved Sandstrom wrote:
>>> Holding back from certain language changes just so someone can
>>> compile a codebase written against Java 5 on a Java 9 compiler, and have
>>> it work, is holding back the entire language.
>>
>> Why is this a problem?
>>
>> Firstly, you can use `javac -source 1.3` to compile old code, can't you?
>>
>
> No. Not if you want some of the new features. [...]
>
> You also have to make sure that all your third-party libraries for
> that build conform to the older spec.
>
> Targeting an old version is an all-or-nothing proposition.
>
All good points but I feel your "No." is more like a "Yes, but".
If everyone at Oracle went mad and Java 1.9 changed the language spec so
that integer arithmetic could throw an IntegerOverflowException,
presumably they could arrange things in the compiler (and JVM) so that
the `-source 1.5` option would compile the code such that integer
operations would never throw an IntegerOverflowException thus satisfying
Arved's objection - couldn't they?
>> Secondly, a future version of Java could introduce some mechanism such
>> as in-line compiler directives that turn new
>> compiler-behaviours/language-features on for specified classes or for
>> specified sections of code (I'm thinking of Perl's `use feature` pragma
>> but I'm sure this sort of idea exists in other languages).
>>
>
> It'll come down to someone's perception of how valuable that feature
> is against the cost.
Sure (assuming you're talking about the cost of adding that feature to
javac and JVM etc), I'm speaking hypothetically.
@IntegerOverflowExceptions(true)
int c = a + b;
@IntegerOverflowExceptions(false)
It looks horrid to me, and presumably there's lots of issues to
overcome, better syntax to achieve the same ends, but essentially, if
Sunacle felt it worthwhile, something could be done to introduce new
behaviours whilst making them optional for existing code that those
behaviours would break?
Whilst I personally (think I) have no need for arithmetic overflow
checking of this sort, I imagine some clever language designers could
provide for it in a way that didn't break existing crypto libraries that
rely on such overflows being ignored.
Perhaps I'm wrong, but people seem to be saying "you just can't do this
because it would break existing code" - I haven't grasped why those
people are sure this is the case.
Despite the above, I'm in favour of keeping the language relatively simple.
--
RGB
[toc] | [prev] | [next] | [standalone]
| From | Martin Gregorie <martin@address-in-sig.invalid> |
|---|---|
| Date | 2011-07-21 12:43 +0000 |
| Message-ID | <j096t3$7rj$2@localhost.localdomain> |
| In reply to | #6333 |
On Thu, 21 Jul 2011 12:11:55 +0100, RedGrittyBrick wrote:
> Sure (assuming you're talking about the cost of adding that feature to
> javac and JVM etc), I'm speaking hypothetically.
>
> @IntegerOverflowExceptions(true)
> int c = a + b;
> @IntegerOverflowExceptions(false)
>
> It looks horrid to me, and presumably there's lots of issues to
> overcome, better syntax to achieve the same ends, but essentially, if
> Sunacle felt it worthwhile, something could be done to introduce new
> behaviours whilst making them optional for existing code that those
> behaviours would break?
>
Agreed, but there's another way to handle this in Java that would
probably cater for most overflow and out of range requirements without
affecting existing programs or the language at all:
Just add range checking constructors to Integer and friends, e.g:
Integer boundedValue = new Integer(0,1,10);
to declare an Integer, initialised to zero and with the range 1:10. The
overheads would be minimal if the checks were only enabled if limits were
added. It could either throw an unchecked exception or provide a range
checking method:
if (!boundedValue.isInRange()) {...}
to check the current value or the possibly more useful:
if (boundedValue.setChecked( ( a + b ) / c )) {...}
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
[toc] | [prev] | [next] | [standalone]
Page 11 of 14 — ← Prev page 1 … 9 10 [11] 12 13 14 Next page →
Back to top | Article view | comp.lang.java.programmer
csiph-web