From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 59724 invoked by alias); 22 Jun 2017 12:01:46 -0000 Mailing-List: contact libffi-discuss-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libffi-discuss-owner@sourceware.org Received: (qmail 59709 invoked by uid 89); 22 Jun 2017 12:01:45 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=complaints, H*Ad:U*libffi-discuss, H*F:U*green, kaz X-HELO: mail-ua0-f171.google.com Received: from mail-ua0-f171.google.com (HELO mail-ua0-f171.google.com) (209.85.217.171) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 22 Jun 2017 12:01:44 +0000 Received: by mail-ua0-f171.google.com with SMTP id 70so14635976uau.0 for ; Thu, 22 Jun 2017 05:01:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ogAiWpOod6iF8gEnTyPDocsxjG2UGQ7elaMs8c3xLvs=; b=I6rRiRelxRYZCxTJhGHlpVgw2cyORnb+UMeqLs+XKCZ8wK85FkOgs4bR//o1JSKgZH f4dZtPKqZpVetrW5T8YloECR4RdOUBUg9HEgZjObTPnII8f9IWV/GBNd7sFAXEeQun1f 3I1NileqVUEIL8wGDjlonkENcptNVcG4/1O0YgvFq6eo+1YDjmSneE/ctu8+vLUBinnd NFya3rV3l9XJbAI5SmKtzlASSpG1PC6ZyYcy5s1YJETBifDy4tuygGhN47oiVq9+ZJ+t 98Wuj2e9P8sKbetkKXIaKQf+pqsSCwzv0ksqKGbQtfzKPWiGVLcn+9XHMWhjMrHoidpj QlQw== X-Gm-Message-State: AKS2vOxniA6UTXAahwm/yteZ/ynXS9OYtF2K8kjHFFP6SlP7ydLVaImI AQTjANxg31G3les/s1xvfgJ9P+f5NoMI X-Received: by 10.159.55.233 with SMTP id q96mr1711450uaq.70.1498132901089; Thu, 22 Jun 2017 05:01:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.15.82 with HTTP; Thu, 22 Jun 2017 05:01:40 -0700 (PDT) In-Reply-To: References: From: Anthony Green Date: Thu, 22 Jun 2017 12:01:00 -0000 Message-ID: Subject: Re: Does a FFI_STRUCT type really need the elements array? To: Kaz Kylheku Cc: "libffi-discuss@sourceware.org" Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2017/txt/msg00016.txt.bz2 Hi Kaz, There are complexities around dealing with structs with nested struct elements. It sounds like yours is a special case, where you are doing a lot of work that is normally done by libffi, which is too bad. The libffi API is far from perfect, but this is one area where there have been few complaints. That being said, it would be interesting to hear a more fully formed proposal that could be considered prior to a major API breaking release. AG On Wed, Jun 21, 2017 at 10:34 PM, Kaz Kylheku wrote: > Hi libffi users, > > Here is the thing. Suppose I have a sophisticated FFI implementation > which uses libffi. Of course I've done all the struct layout calculations > yourself: the offset of every member, taking into account its alignment to > generate any padding in between them and at the end. (I need this in > situations > not involving libffi!) > > Yet, I have to mirror this information in the libffi data structure: > a FFI_STRUCT type has to have an elements[] array of types. Presumably > libffi just walks these, redundantly doing the same calculations to get > the offset of every member, total size with padding and alignment. > > Can't we dispense with the elements[] array and just punch in the size > and alignment values into the struct type (that are supposed to be left > zero?) > > Or is there some compromise: a one-element elements[] array (well two, with > null termination), where a single element indicates the size and > alignment somehow. > > Or how about a one-element array whose one and only pointer is the > null terminator; with the size and alignment punched in: would that > work? > > It's wasteful to allocate, initialize and free these arrays and to have > libffi walking over them. > > Any words of wisdom? >