From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p0QN86OG023264 for ; Thu, 27 Jan 2011 00:08:06 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuQLAC83QE1V2gB4Zmdsb2JhbACWWo41DQsICBIkvGoNhUIEkAo X-IronPort-AV: E=Sophos;i="4.60,382,1291590000"; d="scan'208";a="96949011" Received: from emailfrontal1.citycable.ch ([85.218.0.120]) by mail1-smtp-roc.national.inria.fr with SMTP; 27 Jan 2011 00:08:03 +0100 X-Alinto-smtpauth-localdomain: Yes Received: from seldon (unknown [85.218.92.99]) (Authenticated sender: guillaume.yziquel@citycable.ch) by emailfrontal1.citycable.ch (Postfix) with ESMTPA id 486AF12C186; Thu, 27 Jan 2011 00:08:02 +0100 (CET) Received: from yziquel by seldon with local (Exim 4.72) (envelope-from ) id 1PiESa-0001PV-6z; Thu, 27 Jan 2011 00:07:32 +0100 Date: Thu, 27 Jan 2011 00:07:32 +0100 From: Guillaume Yziquel To: caml-list@inria.fr Message-ID: <20110126230732.GL4195@localhost> References: <20110126221756.GA5907@vaio.jimpryor.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20110126221756.GA5907@vaio.jimpryor.net> User-Agent: Mutt/1.5.20 (2009-06-14) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id p0QN86OG023264 Subject: Re: [Caml-list] Magic with fun (type t) ... ? Le Wednesday 26 Jan 2011 à 17:17:56 (-0500), Jim Pryor a écrit : > > It appears that non-heap values are always getting magicked into ints. > > Has this been noted before? I noted this. It seems to me that the toplevel's behaviour has changed in the 3.12 release. It doesn't seem to rely on available type information to display the exception, but rather seems to inspect the low-level layout of the exception's content. None and 0 are the same. Strings are not. I may be mistaken, but it seems to that I was raising exceptions in the toplevel with arguments that were custom blocks. This made the toplevel segfault when trying to read the custom block. I feel that this is a regression from previous OCaml toplevel behaviour, but I'm not so sure. -- Guillaume Yziquel