https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122312
--- Comment #3 from Alejandro Colomar <[email protected]> --- (In reply to Harald van Dijk from comment #2) > This example looks more complicated than it needs to be, it looks like the > nested function is only used to attempt implicit conversion to the correct > fake parameter type. There are other ways that that can be done that do not > involve additional functions, e.g.: > > #define my_strtol_(QChar, s_, endp_, base_) \ > ({ \ > QChar *s = s_; \ > QChar **endp = endp_; \ > int base = base_; \ > strtol(s, (char **) endp, base); \ > }) > > #define my_strtol(s, endp, base) my_strtol_(QChar_of(s), s, endp, base) > > Is there a case where this cannot be used and a nested function would be > required and this new extension would improve things? It avoids the need for local_ uglified variables, which can fail in case of nested macros. But I was using it as a step to having literal functions (i.e., compound literals with function type), which would be even simpler: #define my_strtol_(QChar, ...) \ ((static long \ (QChar *s, QChar **endp, int base)) \ { \ return strtol(s, (char **) endp, base); \ }(__VA_ARGS__)) #define my_strtol(s, endp, base) my_strtol_(QChar_of(s), s, endp, base) And that would also avoid the statement expression, which creates a new scope that have a bad interaction with compound literals passed as arguments.
