wide function pointer type

Martin Uecker ma.uecker@gmail.com
Mon Oct 18 05:33:18 GMT 2021


Hi Anthony,

Am Sonntag, den 17.10.2021, 19:35 -0400 schrieb Anthony Green:
> Hi Martin,
> 
>   I haven't read the whole proposal yet, but I'll try to this week.  I
> did, however, read the first paragraph, and it says:  "Trying to use
> regular function pointers for callbacks with data requires run-time
> code generation (e.g. nested functions in GCC or XL C, and closures in
> libffi [1]) but this is complex, inefficient, and problematic from a
> security point of view."
> 
>   This is no longer true for libffi on the important Linux platforms.
> We use static code templates that are placed in memory at a fixed,
> predetermined distance from the data they reference.  There is no
> runtime code generation.  Well, to be fair, perhaps it is still
> complex, but it's far more secure than before.
> 
>   Thanks for sharing.  I'm not a language expert, but I know others here are.

Thank you for your comments! I had to submit this to WG14 to meet
the deadline for C23. So the final version (so far) is here:

 http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2787.pdf

Of course, it is still possible to modify the proposal later.

It is great to hear that libffi can create trampolines
without run-time code generation! We previously discussed
such an approach also for GCC, but nothing was implemented.


Martin


> AG
> 
> On Sun, Oct 10, 2021 at 7:32 AM Martin Uecker via Libffi-discuss
> <libffi-discuss@sourceware.org> wrote:
> > 
> > 
> > Hi all,
> > 
> > I will propose a wide function pointer type (actually
> > a wide function type) to WG14 for C23 as a common
> > type for callbacks, closures, which now require an
> > additional void pointer argument in C APIs. This
> > is intended to be compatible with ABIs with now
> > use a static chain register.
> > 
> > An early draft can be found here:
> > 
> > http://wwwuser.gwdg.de/~muecker1/wide_v4.pdf
> > 
> > 
> > I thought you might be interested and I would love
> > to hear your feedback.
> > 
> > Martin
> > 
> > 
> > 



More information about the Libffi-discuss mailing list