From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <garrigue@math.nagoya-u.ac.jp>
X-Original-To: caml-list@yquem.inria.fr
Delivered-To: caml-list@yquem.inria.fr
Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39])
	by yquem.inria.fr (Postfix) with ESMTP id 57431BDDB
	for <caml-list@yquem.inria.fr>; Sun,  4 Sep 2005 03:57:48 +0200 (CEST)
Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1])
	by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j841vk2k025281
	for <caml-list@yquem.inria.fr>; Sun, 4 Sep 2005 03:57:47 +0200
Received: from localhost (suiren [130.54.16.25])
	by kurims.kurims.kyoto-u.ac.jp (8.13.1/8.13.1) with ESMTP id j841vi3B023597
	for <caml-list@yquem.inria.fr>; Sun, 4 Sep 2005 10:57:44 +0900 (JST)
Date: Sun, 04 Sep 2005 03:58:35 +0200 (CEST)
Message-Id: <20050904.035835.07647783.garrigue@math.nagoya-u.ac.jp>
To: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Unsafe features
From: Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>
In-Reply-To: <87slwmjkdx.fsf@mid.deneb.enyo.de>
References: <87y86elcb2.fsf@mid.deneb.enyo.de>
	<F11D2D94-E089-4C01-8344-E54DC75764BB@wanadoo.fr>
	<87slwmjkdx.fsf@mid.deneb.enyo.de>
X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Miltered: at concorde with ID 431A549A.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)!
X-Spam: no; 0.00; caml-list:01 florian:01 val:01 heap:01 val:01 oops:01 ...:98 integer:01 unsafe:01 int:01 int:01 jacques:01 jacques:01 underlying:01 segmentation:02 
X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr
X-Spam-Level: 
X-Spam-Status: No, score=0.4 required=5.0 tests=DNS_FROM_RFC_ABUSE 
	autolearn=disabled version=3.0.3

From: Florian Weimer <fw@deneb.enyo.de>
> I gave it a try and got:
> 
> # let x : int = Obj.magic "x";;
> val x : int = 67381588
> # x;;
> - : int = 67381588
> # 
> 
> The "67381588" is just half the integral value of a heap address
> (because of the tag bit, I presume).  And looking at the ltrace
> output, it seems that it is indeed close to the storage area of that
> string.

You are right indeed. Here is another way to see that this only
changes the apparent type of the underlying value:

# let x : int = Obj.magic (String.create 3);;
val x : int = 67389852
# Gc.full_major();;
- : unit = ()
# x;;
- : int = 68129330

Oops, here is an integer that changes with the GC...

Worse:
# let y = x+13;;
val y : int = 67407805
# Gc.full_major();;
Segmentation fault

Jacques