__func__ is available since C99. Zabbix, enter the modern world!

https://gcc.gnu.org/c99status.html says that __func__ is supported since GCC 2.95.

I tested that __func__ works on Centos 2.1 with GCC 2.96 (actually almost 3.0 as described in https://gcc.gnu.org/gcc-2.96.html (thanks to asitals for link).
VS 2017 tested - it also supports __func__.
Could be good idea to move to __func__.

Issue was discussed with sasha and andris. We decided to:

• leave __function_name in Zabbix 3.0 and 4.0, fix values where necessary;
• replace __function_name with __func__ in Zabbix 4.2.

 <sasha> I agree.

Where __func__ is NOT supported ?

• Visual Studio 2010. source: https://github.com/OpenVPN/openvpn/pull/24/files. See how __FUNCTION__ is used instead also in https://github.com/OpenVPN/openvpn/commit/9884e20810bda737c7708ff587e09cc0bb8475c7
• Discussion in Chromium-dev maillist shows Visual Studio 2014 supports it.
• Red Hat Linux in 2003 with Egcs 1.1.2 compiler did not support __func__, but supported __FUNCTION__. Source: https://bugzilla.redhat.com/show_bug.cgi?id=104627

https://www.boost.org/doc/libs/1_69_0/boost/current_function.hpp has excellent info which compilers and versions use __func__, __FUNCTION__ or even __PRETTY_FUNCTION__. This link was found in https://stackoverflow.com/questions/7008485/func-or-function-or-manual-const-char-id - see also other answers there.

<asitals> Discussion in Chromium-dev maillist was about C++. I'm wondering if it is any different in C in VS. Boost's header file is C++, too. Someone on stackoverflow mentioned that __func__ "exists in C99 / C++11".

It looks like GCC had __FUNCTION__ even before __func__ - https://gcc.gnu.org/onlinedocs/gcc/Function-Names.html

As for OpenVPN, I was thinking about similar "workaround". While they don't seem to be the same thing (one might be local static const array of char, another might be macro that holds string literal and is defined only inside functions), it should work as long as we don't use it as a "macro that holds string literal".

Either way, it looks like it is possible to create a working "cross-platform/cross-compiler" solution that would not require creating local variables and filling them manually. If user won't be able to compile from sources with some exotic compiler because of __func__, one can always define it as something that works with that compiler (or even define it as an empty string, if debugging is not necessary).

Small demo with GCC 8.2:
C program:

#include <stdio.h>
int     main(int argc, char **argv)
{
        printf("           __func__: %s\n", __func__);
        printf("__PRETTY_FUNCTION__: %s\n", __PRETTY_FUNCTION__);
}

produces:

           __func__: main
__PRETTY_FUNCTION__: main

C++ program

#include <iostream>
int     main(int argc, char **argv)
{
        std::cout << "           __func__: " <<  __func__ << "\n";
        std::cout << "__PRETTY_FUNCTION__: " << __PRETTY_FUNCTION__ << "\n";
}

produces:

           __func__: main
__PRETTY_FUNCTION__: int main(int, char**)

Seems like we can use __func__, but better be ready to fallback to _FUNCTION__.

Available in versions:

• pre-3.0.27rc1 r92076
• pre-4.0.7rc1 r92079
• pre-4.2.1rc1 r92101
• pre-4.4.0alpha1 r92102,r92111