From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from omta002.cacentral1.a.cloudfilter.net (omta002.cacentral1.a.cloudfilter.net [3.97.99.33]) by sourceware.org (Postfix) with ESMTPS id 7D43B3857B91 for ; Tue, 31 May 2022 16:55:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7D43B3857B91 Received: from shw-obgw-4001a.ext.cloudfilter.net ([10.228.9.142]) by cmsmtp with ESMTP id w0RHnZdhwWi4Qw59cn9u7G; Tue, 31 May 2022 16:55:36 +0000 Received: from kylheku.com ([70.79.182.7]) by cmsmtp with ESMTPA id w59tnfzflE4biw59tnxfWf; Tue, 31 May 2022 16:55:54 +0000 X-Authority-Analysis: v=2.4 cv=YdeuWidf c=1 sm=1 tr=0 ts=6296489a a=pMSlDXUwMa7SJ1EIez8PdQ==:117 a=pMSlDXUwMa7SJ1EIez8PdQ==:17 a=xqWC_Br6kY4A:10 a=kj9zAlcOel0A:10 a=oZkIemNP1mAA:10 a=KxCsr730AAAA:8 a=CCpqsmhAAAAA:8 a=yeCJHTJyPeU2ZkA1rV0A:9 a=CjuIK1q_8ugA:10 a=_T5_SZ4BPdQ8elZ3MUhu:22 a=ul9cdbp4aOFLsgKbc677:22 Received: from localhost ([::1] helo=mail.kylheku.com) by kylheku.com with esmtp (Exim 4.94.2) (envelope-from ) id 1nw54w-009vDf-9h; Tue, 31 May 2022 09:55:51 -0700 MIME-Version: 1.0 Date: Tue, 31 May 2022 09:55:51 -0700 From: Kaz Kylheku To: dancol@dancol.org Cc: DJ Delorie , Anthony Green , DJ Delorie via Libffi-discuss Subject: Re: Change in libffi behaviour -- large struct args In-Reply-To: <1811b03a668.2829.cc5b3318d7e9908e2c46732289705cb0@dancol.org> References: <1811b03a668.2829.cc5b3318d7e9908e2c46732289705cb0@dancol.org> User-Agent: Roundcube Webmail/1.4.13 Message-ID: <264bcf76fd6434360ab7d763c2a7f68f@kylheku.com> X-Sender: kaz@kylheku.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4xfOcws7WeeFYUVc8lNGJihJREZ2J22qvKhh7Cldfa/eL5UgOzlkUj/BQi4Tt2c4GY03nMKeGy0YYk0Tcb5GA56Ks4HNn0NwZc8AHlJOcVkKa/PNudCquC D4YUVniZs/MJutLnwcEw1l0lLa4/UVQpCmtY+iooH+r/52uvmHRF5gdHLM1Ilc2D3CLE7fTKtRLGm+PBelFxTypA8nbGPyRIDxKCY+xrEVRc/52lmROL6ome bpf8PJnSefwWRBKngUjahGUZz8DzZKPbbN2HG79N0fk= X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, HEADER_FROM_DIFFERENT_DOMAINS, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: libffi-discuss@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libffi-discuss mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2022 16:55:57 -0000 On 2022-05-31 09:47, dancol@dancol.org wrote: > On May 31, 2022 11:53:56 DJ Delorie via Libffi-discuss wrote: > >> While this is technically an ABI change, if the "old" ABI never worked, >> I can't see how this would break anything by changing. >> >> I will add that passing structs is likely more complex than you think ;-) > > The problem is that whether the old API was broken or not, changing it can break working code. What do the libffi people think about using symbol versioning? ELF symbol versioning keeps old binaries working. Newly recompiled programs will break in cases when recompilation alone doesn't fix the issue. Versioning works really well for things like new members being added to a structure, where newly recompiled code picks up the new declaration and so recompiling == fixing. It won't work in a situation where some FFI-using code has worked around for some libffi behavior and expects that not to be moving target; then someone has to fix the code. People recompile code all the time without fixing anything in it.