From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id D93CF7F616 for ; Fri, 24 Feb 2017 11:38:21 +0100 (CET) Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=rich@annexia.org; spf=Pass smtp.mailfrom=rich@annexia.org; spf=Pass smtp.helo=postmaster@annexia.org Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of rich@annexia.org) identity=pra; client-ip=80.68.91.176; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="rich@annexia.org"; x-sender="rich@annexia.org"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of rich@annexia.org designates 80.68.91.176 as permitted sender) identity=mailfrom; client-ip=80.68.91.176; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="rich@annexia.org"; x-sender="rich@annexia.org"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of postmaster@annexia.org designates 80.68.91.176 as permitted sender) identity=helo; client-ip=80.68.91.176; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="rich@annexia.org"; x-sender="postmaster@annexia.org"; x-conformance=sidf_compatible; x-record-type="v=spf1" IronPort-PHdr: =?us-ascii?q?9a23=3AOKJ04xZFEHHhps3tMNeVl+7/LSx+4OfEezUN459i?= =?us-ascii?q?sYplN5qZpsu8bnLW6fgltlLVR4KTs6sC0LuL9fq4EjVcqdbZ6TZZL8wKD0dEwe?= =?us-ascii?q?wt3CUeQ+e9QXXhK/DrayFoVO9jb3RCu0+BDE5OBczlbEfTqHDhpRQbGxH4KBYn?= =?us-ascii?q?br+tQt2a3IyL0LW58pjXJgFJnyaVYLVoLRzwox+CmNMRhN4oEKc6yhLTrjN3Pc?= =?us-ascii?q?EQjUFvI1+I1V6o/Ma7/LZq9SJdq/MosclaXvOpLOwDUbVEAWF+YCgO78rxuEyb?= =?us-ascii?q?QA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AdBQDrC7BY/7BbRFBdHQEFAQsBGAEFA?= =?us-ascii?q?QsBgyVhhBabDgaWV4INLIkfQBcBAQEBAQEBAQEBAWEogjMggl57EyEFKIobEQq?= =?us-ascii?q?cdZIri3EFhgc7ihmFGQWcGgGGc4skkSNIkmUhAjSBAGEIhEVEHYFhQDqKJAEBA?= =?us-ascii?q?Q?= X-IPAS-Result: =?us-ascii?q?A0AdBQDrC7BY/7BbRFBdHQEFAQsBGAEFAQsBgyVhhBabDga?= =?us-ascii?q?WV4INLIkfQBcBAQEBAQEBAQEBAWEogjMggl57EyEFKIobEQqcdZIri3EFhgc7i?= =?us-ascii?q?hmFGQWcGgGGc4skkSNIkmUhAjSBAGEIhEVEHYFhQDqKJAEBAQ?= X-IronPort-AV: E=Sophos;i="5.35,200,1484002800"; d="scan'208";a="261922941" Received: from annexia.org ([80.68.91.176]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 24 Feb 2017 11:38:21 +0100 Received: from rich by annexia.org with local (Exim 4.84_2) (envelope-from ) id 1chDGU-0000Xl-Oz for caml-list@inria.fr; Fri, 24 Feb 2017 10:38:18 +0000 Date: Fri, 24 Feb 2017 10:38:18 +0000 From: "Richard W.M. Jones" To: caml-list@inria.fr Message-ID: <20170224103818.GI28111@annexia.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Subject: [Caml-list] Initializing CAMLlocalX values to Val_unit We just corrected a crashing bug in some C bindings. The code essentially did: CAMLlocal1 (exn); call_some_function (&exn); if (exn != Val_unit) { // The function wants to raise an exception ... caml_raise (exn); } This crashed with OCaml 4.01 because of Mark's upstream change to how CAMLlocalX is initialized. https://github.com/ocaml/ocaml/commit/05100e597e4296a2e79e6c2d9cd75b7e1cc595c9 https://github.com/ocaml/ocaml/commit/2dd92969d254ddae7b49f1478a2ef69ccf70ad42 In OCaml <= 4.01, there was an implicit initialization to 0 in the macro. In some later version of OCaml this was changed to implicitly initialize to Val_unit instead. I have no problem with this change, and the code above was obviously buggy with the older versions of OCaml. However I do have some questions ... (1) The documentation says: "The macros CAMLlocal1 to CAMLlocal5 declare and initialize one to five local variables" which is technically correct, but not very useful. Is the initialization with Val_unit a permanent change, and will it be documented as ABI? (2) We have lots of existing code which does: CAMLlocal1 (v); // some code here which might allocate and call the GC v = ... It's my understanding that such code might crash with the older versions of OCaml, because when it calls the GC it will find a local root which is initialized to 0. We want to continue to support the older versions (back to 3.12 in fact), so should we change it all to: CAMLlocal1 (v); v = Val_unit; // some code here which might allocate and call the GC v = ... ? Interestingly none of this code has actually crashed in production as far as I'm aware. Rich.