[asterisk-dev] elimination of -fnested-functions on gcc + -fblocks on clang

[Jaco Kroon]

Hi All,

Long story short:  I'd like to potentially eliminate the use of those
options.  They're used for RAII_VAR (and only RAII_VAR assuming I'm not
missing something obvious).

Long story:

They're use is in conjuction with __attribute__((cleanup(...))) (which
is supported by both gcc and clang, and probably other compilers).

The use for -fnested-functions and -cblocks is to get a clean prototype
for the destructor functions, assuming type T:

void destructor(T v);

Compared to that which __attribute__((cleanup(...))) expects:

void destructor(T* v);

The issue came up when trying to enable use of clang as compiler for
asterisk on Gentoo Linux.  https://bugs.gentoo.org/731280 contains the
details.

There are 125 such destructor functions, and ~2250 uses of them, from
what I counted with grep and sed.

If there is appetite for this, I would like to propose that they be
updated to have the trampoline declared as static inline along with the
destructor (for above example), eg:

static inline void dtor_tramp_destructor(T* v) { destructor(*v); }

instead of as nested functions or using fblocks.

This can be done with simple(ish) RAII_DESTRUCTOR(descructor, T) macro:

#define RAII_DESTRUCTOR(n, t, vn) static inline void dtor_tramp_ ## n
(t* v) { n(*v); } void n(t vn)

To be used either as a prototype or definition (Lack of ; at end of macro):

RAII_DESTRUCTOR(T, destructor, arg);

and then later just implement void destructor(T v), or as a direct
definition:

RAII_DESTRUCTOR(T, destructor, arg)
{
   // code here to interact on arg
}

RAII_VAR then needs to just be updated to not declare and define the
trampoline functions at all, but instead use
__attribute__((cleanup(dtor_tramp_ ## dtor)))

This will eliminate the need on libBlocksRuntime (along with -fblocks)
in the case of using clang on Linux, and nested-functions for gcc.  It's
also likely to provide for support for other c compilers (don't have
examples off the top of my head, but in my years I've bumped onto
proprietary cross-compilers for various chips, and of course, intel c
compiler aka icc).

I don't object to keeping things as is, I am however wondering if there
would be appetite for such a patch that could eliminate the compiler
dependencies on gcc / clang.  I don't mind writing the patch either, and
would be happy to do so if there is interest in this (I have already
done a 10-line POC of the concept, and would probably be able to adjust
this into a autoconf test for __attribute__((cleanup(...))) if such a
test doesn't already exist in autoconf).

Kind Regards,
Jaco