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 645077FD2F for ; Fri, 24 Feb 2017 14:59:58 +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=3AqTBLmhHviELqmxzO6XdMa51GYnF86YWxBRYc798d?= =?us-ascii?q?s5kLTJ75psywAkXT6L1XgUPTWs2DsrQf2reQ6firBDNIoc7Y9itdINoUD15NoP?= =?us-ascii?q?5VtjJjKfbNMVf8Iv/uYn5yN+V5f3ghwUuGN1NIEt31fVzYry76xzcTHhLiKVg9?= =?us-ascii?q?fbytScb6xv663OGq+pDVfx4AxH/kOeszf12KqlD4rM0bh8NJLbZ5nhLTpnZOcO?= =?us-ascii?q?NG7WxtLFOX2R3745Hj0oRk9nEagfMq98daXe3FOYF+BZ5fCjk9eShh/szgtTHK?= =?us-ascii?q?Sw2C9noVFGIMnUwbUED+8BjmU8Kp4WPBve1n1XzfZJWuQA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CwAwB9O7BY/7BbRFBdGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBFAEBAQEBAQEBAQEBBwEBAQEBgyWEd5sHAQEBAQEBBoEil0KGIgKCckM?= =?us-ascii?q?UAQEBAQEBAQEBAQFhKIIzBAEdAQSCFgEBAQMBOj8FCwsYCRMSDwUoIYl6BQyvS?= =?us-ascii?q?otBAQEIAgElhgc7hHmKOQWVa4YvAZIXkSNIkmU2IYEBYQg+hk1AiQ+BTwEBAQ?= X-IPAS-Result: =?us-ascii?q?A0CwAwB9O7BY/7BbRFBdGgEBAQECAQEBAQgBAQEBFAEBAQE?= =?us-ascii?q?BAQEBAQEBBwEBAQEBgyWEd5sHAQEBAQEBBoEil0KGIgKCckMUAQEBAQEBAQEBA?= =?us-ascii?q?QFhKIIzBAEdAQSCFgEBAQMBOj8FCwsYCRMSDwUoIYl6BQyvSotBAQEIAgElhgc?= =?us-ascii?q?7hHmKOQWVa4YvAZIXkSNIkmU2IYEBYQg+hk1AiQ+BTwEBAQ?= X-IronPort-AV: E=Sophos;i="5.35,201,1484002800"; d="scan'208";a="261953122" Received: from annexia.org ([80.68.91.176]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 24 Feb 2017 14:58:53 +0100 Received: from rich by annexia.org with local (Exim 4.84_2) (envelope-from ) id 1chGOa-0000Ci-II; Fri, 24 Feb 2017 13:58:52 +0000 Date: Fri, 24 Feb 2017 13:58:52 +0000 From: "Richard W.M. Jones" To: Arlen Cox Cc: caml-list@inria.fr Message-ID: <20170224135852.GJ28111@annexia.org> References: <20170224103818.GI28111@annexia.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: [Caml-list] Initializing CAMLlocalX values to Val_unit On Fri, Feb 24, 2017 at 08:43:38AM -0500, Arlen Cox wrote: > > ? Interestingly none of this code has actually crashed in production > > as far as I'm aware. > > I'm fairly certain this is because the OCaml runtime checks pointers > to ensure that they're in the OCaml heap before tracing them. OK I see - I knew this but didn't know if it applied to NULL pointers too. > I don't > know how this holds up historically, but last time I looked (4.03) > when tracing, OCaml runs Classify_addr(a) on addresses to determine if > they should be traced into. Because of this, NULL pointers will not > be followed (and thus not crash) and perhaps more interestingly raw > (naked) pointers that don't point to anything in an OCaml-registered > page will also not be traced. > > There is a define related to NAKED_POINTERS that if defined will > improve performance by disabling the check for Is_in_heap(a) (macro > for Classify_addr). Naked pointer support can be disabled during > configure (--no-naked-pointers) and that may make code that does not > initialize things correctly crash. Naked pointers are checked in the > default configuration. Thanks (and also to Gerd's response). Rich. -- Richard Jones