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 mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 682287FEF2 for ; Sun, 28 Feb 2016 01:56:40 +0100 (CET) IronPort-PHdr: 9a23:wTt5bB0i+pR3G120smDT+DRfVm0co7zxezQtwd8ZsegRLPad9pjvdHbS+e9qxAeQG96LtLQa1qGP4/2ocFdDyKjCmUhKSIZLWR4BhJdetC0bK+nBN3fGKuX3ZTcxBsVIWQwt1Xi6NU9IBJS2PAWK8TWM5DIfUi/yKRBybrysXNWC0ILpiqvrq8CbSj4LrQT+SIs6FA+xowTVu5teqqpZAYF19CH0pGBVcf9d32JiKAHbtR/94sCt4MwrqHwI6LoJvvRNWqTifqk+UacQTHF/azh0t4XXskzmRA+E4X8ZGkAfjhNMAAGNuBT/V4v4tijznuV40Siee8bxSOZndy6l6vJJRQXljTZPBjc99GbPwphhhaZfpwqJqBl2woqSa4aQYqktNpjBdM8XEDISFv1aUDZMV8blN9MC Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=yallop@gmail.com; spf=Pass smtp.mailfrom=yallop@gmail.com; spf=None smtp.helo=postmaster@mail-qg0-f46.google.com Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of yallop@gmail.com) identity=pra; client-ip=209.85.192.46; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="yallop@gmail.com"; x-sender="yallop@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of yallop@gmail.com designates 209.85.192.46 as permitted sender) identity=mailfrom; client-ip=209.85.192.46; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="yallop@gmail.com"; x-sender="yallop@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-qg0-f46.google.com) identity=helo; client-ip=209.85.192.46; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="yallop@gmail.com"; x-sender="postmaster@mail-qg0-f46.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BnAAB+RNJWji7AVdFehAxeDwa6ZYFmIYVyAoEgBzkTAQEBAQEBAQEQAQEBAQcLCwkfMYItghQBAQEDARIRHQEbHQEDAQsGBQsDCgICJgICIQEBEQEFARwGEyKHZwEDCggOokiBMT4xizSBaYJXhFIKGScNUYNsAQEBAQEFAQEBAQEVAQEECgRtiVGCOoR7gToFlwyFWYYVgXSOdIcGhgYRHoEPIQGCNgoUCIFIPC6INwEBAQ X-IPAS-Result: A0BnAAB+RNJWji7AVdFehAxeDwa6ZYFmIYVyAoEgBzkTAQEBAQEBAQEQAQEBAQcLCwkfMYItghQBAQEDARIRHQEbHQEDAQsGBQsDCgICJgICIQEBEQEFARwGEyKHZwEDCggOokiBMT4xizSBaYJXhFIKGScNUYNsAQEBAQEFAQEBAQEVAQEECgRtiVGCOoR7gToFlwyFWYYVgXSOdIcGhgYRHoEPIQGCNgoUCIFIPC6INwEBAQ X-IronPort-AV: E=Sophos;i="5.22,512,1449529200"; d="scan'208";a="166199996" Received: from mail-qg0-f46.google.com ([209.85.192.46]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 28 Feb 2016 01:56:39 +0100 Received: by mail-qg0-f46.google.com with SMTP id y9so93394222qgd.3 for ; Sat, 27 Feb 2016 16:56:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=4KlG/PEnEUpZjpUJyYg9G162Q2MD+ubdnaDsAlYcT7c=; b=rJ3v71AU5Tc6VQjrfauZSX3J8z/BO7b0WFhq6zOSwBksrqvxfAE2ploMAT8wKNfXiE MyEe1GdQ2jhlUgOi0CQoorkZJLxhqLc1WRH/f+Zc9RbVTYOyNdGjxXr+7hRcr2hV82PP D0vT2ShIVRGY22GHatGTlGoEEV4fOJx3jBQVlL1QyQYqTHeXsPOJ8+S3CPnYjC8T2A07 AXCHMsH6W3pSVo5TnyCw5CIFDuGsdUED/1sKwFK6bpbcV0zlyi62IJRQpMUQCu7NOu6+ hq0wdXF+vzQWTGfQBEzw0pv/aP3Qy0LOwnTvOStCfrTo8v5h9fIWNGAULWy7JHfiQS6F eDXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=4KlG/PEnEUpZjpUJyYg9G162Q2MD+ubdnaDsAlYcT7c=; b=C1T/XQ4u4HzyTEzmBKOaZeKhgQyurFBbU2tDNxG4aiyNWbwla5d4TAkvCRJ/yCSg0l I/XWwFLox05CAe9WslpHma6trFqBQUYfZqJXVKevxpYnvk12l6jImARbrGv3GyxSGkz/ nqa2wkN+CIRjo6WjSc6Bg7oicY4aUFSzsstt2QMBwjVkYjPO3Eui9PWPtv/QqjGEO0nR uAnemJfhzht2YI5dbCvdgTcyCGhqpPvQ2iv8Pr6gSVwY0041ApvNUYOpy1LO3wBKPPxY zXZtneOmDOgyZwtmaG+B/0LoH9ypVamSh7OmqVHCERNtYX+RobhogxY9FRF6QymmIpkJ XVgw== X-Gm-Message-State: AD7BkJL40ivIh5OOV1Z4RJKBRW0LMV27mWtPFcpZP3AveJRzZEFcVPfy0boRSeIHnqCadmA2wAxbFZzP45Yc5A== MIME-Version: 1.0 X-Received: by 10.140.159.203 with SMTP id f194mr11714318qhf.18.1456620997978; Sat, 27 Feb 2016 16:56:37 -0800 (PST) Received: by 10.55.157.74 with HTTP; Sat, 27 Feb 2016 16:56:37 -0800 (PST) In-Reply-To: <86ziulheva.fsf@gmail.com> References: <86ziulheva.fsf@gmail.com> Date: Sun, 28 Feb 2016 00:56:37 +0000 Message-ID: From: Jeremy Yallop To: Malcolm Matalka Cc: caml-list@inria.fr, ctypes@lists.ocaml.org Content-Type: text/plain; charset=UTF-8 Subject: Re: [Caml-list] ctypes - Advice for binding big structs? Dear Malcolm, On 28/02/2016, Malcolm Matalka wrote: > I have a large/complex struct I am trying to create bindings for > operations on it in Ocaml. I have an API that tells me how many bytes > the struct is so I can allocate it just fine and pass it around to C > functions I've bound with ctypes. But some data in it is accessed via > members. I started implementing a structure in ctypes for it, but it's > getting large and awkward. Are there any best practices around doing > this? The best approach is to use the Cstubs_structs module, which allows you to declare just the parts of the structs that you need to access in your program, and which generates code that uses the C struct declarations to work out sizes, alignments, field offsets, etc. The basic API is the familiar set of functions "structure", "field" and "seal" from the Ctypes module, but the build process is a little more involved. However, in return for the more complex build, all the issues that you're concerned about are addressed. The Cstubs_structs API is not yet very well documented, but there's a brief guide with examples in the pull request that introduced it: https://github.com/ocamllabs/ocaml-ctypes/pull/62 > Some concerns I have: > > - It seems fragile - a different version of the library might have > different members in the struct so keeping my ocaml code in-synch > seems error prone. The Cstubs_structs module addresses this by using generated C code to determine the offsets of fields each time you build your library. > - It's annoying because the struct has a lot of members I don't care > about in my case. I only want access to a few members that have > important details. Since Cstubs_structs retrieves layout rather than computing it you only need to declare the members that you care about. > - The struct is large with lots of types that I don't necessarily want > to create so creating the struct becomes somewhat awkward. If I know > the size of the types I might be able to pretend it's an array of N > chars or something instead of trying to implement the type just to > fill out this struct, but I don't know if that is valid. Again, since Cstubs_structs retrieves struct layout and alignment information from C, you can use Ctypes.make to create struct values, even if you haven't declared all the fields. Kind regards, Jeremy.