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 -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
