From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id SAA20105; Fri, 31 Oct 2003 18:51:22 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id SAA20029 for ; Fri, 31 Oct 2003 18:51:21 +0100 (MET) Received: from pecan.cc.columbia.edu (pecan.cc.columbia.edu [128.59.59.178]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id h9VHpK100220; Fri, 31 Oct 2003 18:51:20 +0100 (MET) Received: from tw304h3.cpmc.columbia.edu (tw304h3.cpmc.columbia.edu [156.111.84.180]) (user=ot14 mech=LOGIN bits=0) by pecan.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id h9VHpIRr027774 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 31 Oct 2003 12:51:19 -0500 (EST) From: Oleg Trott To: Xavier Leroy Subject: Re: [Caml-list] Int overflow in literals Date: Fri, 31 Oct 2003 12:50:55 -0500 User-Agent: KMail/1.5.4 Cc: caml-list@inria.fr References: <1067522012.5880.6.camel@qrnik> <20031031174215.A17345@pauillac.inria.fr> In-Reply-To: <20031031174215.A17345@pauillac.inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200310311250.55112.oleg_trott@columbia.edu> X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 X-Loop: caml-list@inria.fr X-Spam: no; 0.00; oleg:01 oleg:01 caml-list:01 emits:01 emits:01 inclined:01 imho:01 int:01 int:01 arithmetic:01 writes:01 overflow:02 overflow:02 literals:02 literals:02 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Friday 31 October 2003 11:42 am, Xavier Leroy wrote: > > I understand that int overflow is not checked on arithmetic for > > efficiency reasons, but IMHO it would be better if it was checked > > at least in literals. When someone writes 10000000000, he certainly > > does not mean -737418240. > > It caused confusion in a class when someone was interactively testing > > a function with larger and larger inputs. > > This is a very good suggestion. There are several ways to go about this: > > - The lexer emits a warning in case of overflow, and proceeds with > the value modulo the size of the type. > - The lexer emits an error on overflow. > - The int_of_string functions raise an exception on overflow. > > Based on the comments posted so far on this list, and on a quick > discussion with colleagues, I'm inclined toward the third approach > (int_of_string fails in case of overflow). Does anyone know of a use > scenario where this new behavior of int_of_string would be a problem? How much do you think the performance of "typical programs" would be affected (in percent) if +, - and * were also made to raise an exception on overflow? -- Oleg Trott ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners