From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.1.3 Received: from discorde.inria.fr (discorde.inria.fr [192.93.2.38]) by yquem.inria.fr (Postfix) with ESMTP id ECE4CBC0B for ; Thu, 7 Dec 2006 20:43:13 +0100 (CET) Received: from oden.vtab.com (dns.vtab.com [62.20.90.195]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id kB7JhDId027951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 7 Dec 2006 20:43:13 +0100 Received: from oden.vtab.com (oden.vtab.com [127.0.0.1]) by oden.vtab.com (Postfix) with ESMTP id CFBD826EF36; Thu, 7 Dec 2006 20:43:12 +0100 (CET) Received: from virtutech.se (alfredo.hq.vtech [10.0.0.52]) by oden.vtab.com (Postfix) with ESMTP id BA8FB26EF30; Thu, 7 Dec 2006 20:43:12 +0100 (CET) Received: (from mattias@localhost) by virtutech.se (8.11.6/8.11.6) id kB7JhC522308; Thu, 7 Dec 2006 20:43:12 +0100 Date: Thu, 7 Dec 2006 20:43:12 +0100 Message-Id: <200612071943.kB7JhC522308@virtutech.se> From: "=?iso-8859-1?q?Mattias_Engdeg=E5rd?=" To: jonathan.roewen@gmail.com Cc: pal_engstad@naughtydog.com, caml-list@inria.fr In-reply-to: (jonathan.roewen@gmail.com) Subject: Re: [Caml-list] if (n:int) < 0 then (-n) > 0 is FALSE Content-Type: text/plain; charset=iso-8859-1 References: <45785E27.8050804@naughtydog.com> X-Virus-Scanned: ClamAV using ClamSMTP X-j-chkmail-Score: MSGID : 45786ED1.000 on discorde : j-chkmail score : X : 0/20 1 0.000 -> 1 X-Miltered: at discorde with ID 45786ED1.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; mattias:01 mattias:01 bug:01 ocaml:01 compiler:01 statically:01 bug:01 integers:01 trade-offs:01 unboxed:01 bignum:01 31.:98 overflows:01 overflows:01 slower:01 >It's not a bug -- you're relying on 32bit ints when OCaml has only >31bit ints (on 32-bit arch). In C (for example), if you use a plain >int (I believe it'll default to signed), you get the exact same >behaviour when the number overflows 2^31. (Signed overflow is not legal in C (undefined behaviour), and a decent compiler will warn this can be detected statically.) Of course it is a bug - a design bug, since the behaviour is intended and documented, but still a bug. But getting numbers, even integers, right in every respect is hard, and involves trade-offs between performance, correctness and convenience. I would love to have a fast unboxed integer type that automatically overflows to bignum, but it would be a tad slower than the current "int".