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 RAA22495; Sun, 2 Nov 2003 17:25: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 RAA21917 for ; Sun, 2 Nov 2003 17:25:21 +0100 (MET) Received: from mail3.tpgi.com.au ([203.12.160.59]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id hA2GPI105517; Sun, 2 Nov 2003 17:25:18 +0100 (MET) Received: from syd-ts22-2600-088.tpgi.com.au (syd-ts22-2600-088.tpgi.com.au [203.26.30.88]) by mail3.tpgi.com.au (8.11.6/8.11.6) with ESMTP id hA2GNx221656; Mon, 3 Nov 2003 03:24:00 +1100 Subject: Re: [Caml-list] Int overflow in literals From: skaller Reply-To: skaller@ozemail.com.au To: Xavier Leroy Cc: "Marcin 'Qrczak' Kowalczyk" , caml-list@inria.fr In-Reply-To: <20031031174215.A17345@pauillac.inria.fr> References: <1067522012.5880.6.camel@qrnik> <20031031174215.A17345@pauillac.inria.fr> Content-Type: text/plain Message-Id: <1067786588.20731.19.camel@pelican> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 03 Nov 2003 02:23:09 +1100 Content-Transfer-Encoding: 7bit X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 ozemail:01 inclined:01 ocaml:01 int:01 int:01 overflow:02 overflow:02 literals:02 exception:02 string:03 string:03 wrote:03 converts:03 behavior:03 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Sat, 2003-11-01 at 03:42, Xavier Leroy wrote: > - 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? I cannot give a specific example, but I can paint a general scenario: some data used with C is copied to ocaml (as text). For example 0xFFFFFFFF is too large .. but in C it converts to -1 which is not too large :-) Having given this example .. I have to say 'too bad', I think your inclination is correct. [Whatever program extracted the data from C should have handled this] ------------------- 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