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 4FDBA7EEEF for ; Fri, 12 Jun 2015 09:40:03 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of romain.bardou@inria.fr) identity=pra; client-ip=87.98.184.158; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="romain.bardou@inria.fr"; x-sender="romain.bardou@inria.fr"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of romain.bardou@inria.fr) identity=mailfrom; client-ip=87.98.184.158; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="romain.bardou@inria.fr"; x-sender="romain.bardou@inria.fr"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@11.mo3.mail-out.ovh.net) identity=helo; client-ip=87.98.184.158; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="romain.bardou@inria.fr"; x-sender="postmaster@11.mo3.mail-out.ovh.net"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DrAgB3jHpVnJ64YldcxzWCVgKBQ0wBAQEBAQESAQEBAQEGDQkJIS5BBYNdAQEEODsFEQsYCRYPCQMCAQIBRRMIAogvAdVWAQEIAiCKIIEjhDtSFoQXAQSfDIEwjBuGXINbhB+BcAcdgSABAQE X-IPAS-Result: A0DrAgB3jHpVnJ64YldcxzWCVgKBQ0wBAQEBAQESAQEBAQEGDQkJIS5BBYNdAQEEODsFEQsYCRYPCQMCAQIBRRMIAogvAdVWAQEIAiCKIIEjhDtSFoQXAQSfDIEwjBuGXINbhB+BcAcdgSABAQE X-IronPort-AV: E=Sophos;i="5.13,600,1427752800"; d="scan'208";a="164747912" Received: from 11.mo3.mail-out.ovh.net ([87.98.184.158]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/ADH-AES256-SHA; 12 Jun 2015 09:39:43 +0200 Received: from mail136.ha.ovh.net (b9.ovh.net [213.186.33.59]) by mo3.mail-out.ovh.net (Postfix) with SMTP id 79778100C8AF for ; Fri, 12 Jun 2015 09:39:41 +0200 (CEST) Received: from localhost (HELO queueout) (127.0.0.1) by localhost with SMTP; 12 Jun 2015 09:39:41 +0200 Received: from amontsouris-652-1-179-131.w90-24.abo.wanadoo.fr (HELO ?192.168.1.15?) (romain@bardou.fr@90.24.146.131) by ns0.ovh.net with SMTP; 12 Jun 2015 09:39:40 +0200 Message-ID: <557A8CBB.5050306@inria.fr> Date: Fri, 12 Jun 2015 09:39:39 +0200 From: Romain Bardou User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0 MIME-Version: 1.0 To: caml-list@inria.fr References: <20150612052738.GA3684@pllab.is.ocha.ac.jp> In-Reply-To: <20150612052738.GA3684@pllab.is.ocha.ac.jp> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Ovh-Tracer-Id: 10140980462109297184 X-Ovh-Remote: 90.24.146.131 (amontsouris-652-1-179-131.w90-24.abo.wanadoo.fr) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekuddrieekucetufdoteggodetrfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecu X-Validation-by: romain@bardou.fr Subject: Re: [Caml-list] Marshall.from_channel and segmentation fault On 12/06/2015 07:27, Kenichi Asai wrote: > The OCaml manual for the Marshall module says: > >> (Marshal.from_channel chan : type). Anything can happen at run-time >> if the object in the file does not belong to the given type. > > and this "Anything" contains segmentation fault. Is it difficult to > avoid this segmentation fault and, e.g., raise an exception instead? > > Sincerely, > You have to check that you will not dereference invalid pointers. Basically you need to type-check the value at runtime before using it. If you have a runtime representation of the type of your value, you may be able to do so using Obj. But if you have a runtime representation of the type, Marshal suddenly becomes less interesting as you can use this representation to guide serialization anyway. Because of this, Marshal is mostly used when one knows through other means that only values of the right type are deserialized. This means that Marshal should not be used for network applications where the remote peer cannot be trusted to always send values of the right type. An attacker could send an ill-formed value to crash the server, for instance. Or, the remote peer may simply not be up-to-date and use other types for its values. Marshal is better suited to saving data locally. It will still fail if one tries to use values from another application or another version of the same application with incompatible types. In other words it will not be backward compatible when types change, so Marshal is better suited for temporary files. For instance, .cmi files are marshaled values, if I'm not mistaken. To sum up: yes, it is difficult. Cheers, -- Romain Bardou