From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: weis Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id SAA30861 for caml-redistribution@pauillac.inria.fr; Tue, 22 Feb 2000 18:54:29 +0100 (MET) Resent-Message-Id: <200002221754.SAA30861@pauillac.inria.fr> Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id RAA06896 for ; Tue, 22 Feb 2000 17:27:48 +0100 (MET) Received: from miss.wu-wien.ac.at (miss.wu-wien.ac.at [137.208.107.17]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id RAA16951 for ; Tue, 22 Feb 2000 17:27:47 +0100 (MET) Received: (from mottl@localhost) by miss.wu-wien.ac.at (8.9.0/8.9.0) id RAA09713; Tue, 22 Feb 2000 17:27:45 +0100 (MET) From: Markus Mottl Message-Id: <200002221627.RAA09713@miss.wu-wien.ac.at> Subject: Re: Congratulation! Bug found!! (GC & C interfacing problems) To: David.Mentre@irisa.fr (David=?iso-8859-1?q?_Mentr=E9?=) Date: Tue, 22 Feb 2000 17:27:45 +0100 (MET) Cc: caml-list@inria.fr (OCAML) In-Reply-To: from "David=?iso-8859-1?q?_Mentr=E9?=" at Feb 22, 2000 10:16:32 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-From: weis@pauillac.inria.fr Resent-Date: Tue, 22 Feb 2000 18:54:29 +0100 Resent-To: caml-redistribution@pauillac.inria.fr > 3. However, this macro is calling modify (function defined in > byterun/memory.c) which in turn calls the Modify macro (defined in > byterun/memory.h). As Markus said, this macro adds the address > given in argument to a list of memory addresses (ref_table_ptr) > that should be examined by the GC at collection time. [...] > I also subscribe to this documentation revision. I also volunteer, if > needed, to review/rewrite the doc part related to Interfacing C with > OCaml. I guess that the confusion about the real things happening as explained in "3" above comes from "rule 6" in the documentation of the C-interface, which says: Direct assignment to a field of a block, as in Field(v, n) = w; is safe only if v is a block newly allocated by alloc_small; that is, if no allocation took place between the allocation of v and the assignment to the field. In all other cases, never assign directly. This "safe only" and "in all other cases, never assign directly" leaves the impression that the "Field" macro is a bit "evil" and could be avoided, possibly by using this nice "Store_field"-macro. However, it is not only "safe" to use "Field" in this case, it seems (?) that this is the only way to do it correctly. Furthermore, I did not find any documentation on correctly placing values into blocks created with "alloc_final", which seems to be pretty similar to "alloc_small" in this respect. The only information I found concerning "alloc_small" which appears to indicate correct usage is: alloc_small(n, t) returns a fresh small block of size n <= Max_young_wosize words, with tag t. If this block is a structured block (i.e. if t < No_scan_tag), then the fields of the block (initially containing garbage) must be initialized with legal values (using direct assignment to the fields of the block) before the next allocation. The intention of "using direct assignment to the fields" is obviously meant as hint to use the "Field"-macro. Because most people don't know that "Store_field" not only assigns directly, but does unexpected other things, this information does probably not help... Best regards, Markus Mottl -- Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl