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 SAA19637; Thu, 30 Oct 2003 18:59:36 +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 SAA19626 for ; Thu, 30 Oct 2003 18:59:35 +0100 (MET) Received: from decis.be ([194.78.219.157]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id h9UHxY123492 for ; Thu, 30 Oct 2003 18:59:34 +0100 (MET) Received: from decis.be ([192.168.0.20]) (authenticated user fplancke@decis.be) by decis.be (decis.be [194.78.219.157]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 14-md50000000041.tmp for ; Thu, 30 Oct 2003 18:59:49 +0100 Message-ID: <3FA15194.DAA6045F@decis.be> Date: Thu, 30 Oct 2003 18:59:48 +0100 From: Frederic van der Plancke Reply-To: fvdp@decis.be Organization: Decis X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: caml-list@pauillac.inria.fr Subject: Re: [Caml-list] Int overflow in literals References: <1067522012.5880.6.camel@qrnik> <3FA14C4C.2010608@baretta.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Authenticated-Sender: fplancke@decis.be X-Spam-Processed: decis.be, Thu, 30 Oct 2003 18:59:49 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.0.20 X-Return-Path: fvdp@decis.be X-MDaemon-Deliver-To: caml-list@pauillac.inria.fr X-Loop: caml-list@inria.fr X-Spam: no; 0.00; plancke:01 fvdp:01 caml-list:01 baretta:01 marcin:01 'qrczak':01 kowalczyk:01 culprit:01 triggers:01 tad:99 compiler:01 imho:01 alex:01 bytecode:01 int:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Alex Baretta wrote: > > Marcin 'Qrczak' Kowalczyk 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. > > > > I bet the official answer is "It's can't be done because native integers > are 31 bits on 32 bit platforms, 63 bits on 64 bit platforms, so what is > parser supposed to do? Especially in the case of the bytecode compiler." > Although, I suppose something could be done in the toplevel. I think int_of_string is the culprit and must change (last time I checked, int_of_string "10000000000" returned -737418240). (sorry if that's already been done in 3.07, I haven't tried it yet.) There's not much execution time to gain by not letting it check the overflow, and there's no easy way to write a "correct" safety wrapper for that function (as it would have to accept arguments like "-0000000123456789", it would be easier to rewrite it from scratch.) Ditto for int_of_float (int_of_float 10000000000.0 = -737418240), even though there the safety wrapper is easier to write (and the relative loss of execution time would probably be greater.)) I think that understanding "language safety" as "never triggers access violation" is a tad restrictive... Frédéric ------------------- 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