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 AFFE93858C3A for ; Wed, 20 Oct 2021 17:27:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org AFFE93858C3A Received: from shw-obgw-4004a.ext.cloudfilter.net ([10.228.9.227]) by cmsmtp with ESMTP id dD5PmnDtops7PdFNTmPv6f; Wed, 20 Oct 2021 17:27:47 +0000 Received: from kylheku.com ([70.79.163.252]) by cmsmtp with ESMTPA id dFNSmPvOga8XRdFNSmuEAC; Wed, 20 Oct 2021 17:27:47 +0000 X-Authority-Analysis: v=2.4 cv=Ov8sdwzt c=1 sm=1 tr=0 ts=61705193 a=95A0EdhkF1LMGt25d7h1IQ==:117 a=95A0EdhkF1LMGt25d7h1IQ==:17 a=IkcTkHD0fZMA:10 a=SMorJkV_YP8A:10 a=8gfv0ekSlNoA:10 a=p4HfkfbfzqIknsR_sKQA:9 a=QEXdDO2ut3YA:10 Received: from www-data by kylheku.com with local (Exim 4.72) (envelope-from <382-725-6798@kylheku.com>) id 1mdFNR-0008UQ-Ly; Wed, 20 Oct 2021 10:27:45 -0700 To: Florian Weimer Subject: Re: wide function pointer type X-PHP-Originating-Script: 501:rcmail.php MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Oct 2021 10:27:45 -0700 From: "Kaz Kylheku (libffi)" <382-725-6798@kylheku.com> Cc: Martin Uecker , Martin Uecker via Libffi-discuss In-Reply-To: <878ryoxdsn.fsf@oldenburg.str.redhat.com> References: <9362563f8803f575d00c03835d2897b3836a7645.camel@gmail.com> <857da973fe5bbb94a363114262b57d42b35cc1f6.camel@gmail.com> <87czo2hjiq.fsf@oldenburg.str.redhat.com> <8d2ddbb76479ce3ad7f99acb3f0b79a6a8d1440b.camel@gmail.com> <87bl3lgyha.fsf@oldenburg.str.redhat.com> <6a0299e6b3c47cddd88b24d569fca8aeb4717aeb.camel@gmail.com> <87o87lfhi3.fsf@oldenburg.str.redhat.com> <878ryoxdsn.fsf@oldenburg.str.redhat.com> Message-ID: X-Sender: 382-725-6798@kylheku.com User-Agent: Roundcube Webmail/0.9.2 X-CMAE-Envelope: MS4xfAc2Wz5g1F0rhZ8sRO8bCV/6S5Ob4q7w2d4scVruNHqWqeLuID2pp6W9R2uzamPWmLKztPKDDwhci2qfQg5FViG7DEOP/DdTCOSe2pnuzDn6c1M4K4q1 nFRh/7gd5C2mI67csig5IKuo/d+mj0wPYQvnTwwsuSl9/L7TDx/3Ho4LC2ovaUXlvwNMTTvEVVw5dPQ2ej+SxEAdVYr3ivkqi0LxEah2TKVXIi6DsfQGu80t HznhhryE+qKoJImWrm3xpw== X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, FROM_STARTS_WITH_NUMS, HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Wed, 20 Oct 2021 17:27:49 -0000 On 2021-10-20 02:10, Florian Weimer via Libffi-discuss wrote: > Perhaps a set of standard attributes to describe the explicit closure > argument would be useful, though. For what purpose though? If there is some attribute mechanism in the=20 syntax, what translation decision does it drive? Or else, what diagnostic=20 purpose? Variable length arrays use matching names: void f(int x, double array[x]) the size attribute of the array is linked to the x parameter by name. This is semantically important, because inside the function, the run-time size of the array is computable with "sizeof array", and that is derived from the value of x. If the compiler knows that some closure argument c is linked with a function f, what special treatment can it perform? The function could be callable with fewer arguments, such that c is implicitly inserted into the call. Or, perhaps more usefully, we might be interested in diagnosing the situation when the program neglects to pass the context parameter to the function. But if all we have is some parameter attributes, that is of limited use; what if the function want to store those two pieces into some structure, so that some other function will later call f(c, ...). The annotation mechanism would have to be propagated to all the places in the program where the f value can reach; which means additional declaration material in multiple places. If a structure stores a function pointer and context value, we need to be able to relate them in a structure, and so forth. Imagine we had: struct callback { void *c __attribute__((context (f))); void (*f)(void *context); }; Let's use GCC-like attribute syntax with the understanding that the actual syntax could be something else. void fun(void *context _attribute__ ((context (f))), void *other, void (*f)(void *)) { struct callback cb; cb.f =3D f; cb.c =3D other; // ERROR } This function could be diagnosable; however, depending on the exact rules, it could requires data flow techniques, difficult to implement without optimization. The semantic constraint rules could be as simple as: 1. If either the members *f* or *c* are assigned, the other one must be assigned in the same expression, or adjacent statements of a compound statement, such that no other operation intervenes between the assignments. 2. Both members must be assigned from a linked pair. The assigned values are a linked function-context argument pair, or linked function-context members of the same structure. 3. In a struct definition with an initializer, if one linked member has an explicit initializer, the other must have one also, and the values must be a linked pair. The only ingredient missing is the problem to go with this wonderful=20 solution!