From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 7BE3B3858D39 for ; Thu, 21 Oct 2021 09:48:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7BE3B3858D39 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-518-5vuQ2NgGOsG_bK5d0kwI3g-1; Thu, 21 Oct 2021 05:48:30 -0400 X-MC-Unique: 5vuQ2NgGOsG_bK5d0kwI3g-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 43A6410B395B; Thu, 21 Oct 2021 09:48:29 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.194.104]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 0189B60C13; Thu, 21 Oct 2021 09:48:27 +0000 (UTC) From: Florian Weimer To: "Kaz Kylheku (libffi)" <382-725-6798@kylheku.com> Cc: Martin Uecker , Martin Uecker via Libffi-discuss Subject: Re: wide function pointer type 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> Date: Thu, 21 Oct 2021 11:48:26 +0200 In-Reply-To: (Kaz Kylheku's message of "Wed, 20 Oct 2021 10:27:45 -0700") Message-ID: <87zgr2so7p.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-6.4 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham 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: Thu, 21 Oct 2021 09:48:38 -0000 * Kaz Kylheku: > 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 > syntax, what translation decision does it drive? Or else, what > diagnostic purpose? Auto-generation of bindings for languages that have functions with environments. > If the compiler knows that some closure argument c is linked with a > function f, what special treatment can it perform? It can automatically separate the environment/chain pointer from the code pointer and pass them in the right arguments. And a thunk can be create if necessary. > 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. Environment/chain arguments in structs would only need annotating if they are publicly exposed on API boundaries. I am not convinced this is a common occurrence. With the new function pointer type, all these types have to be duplicated, to preserve compatibility with older C versions. That seems rather unlikely. Thanks, Florian