[illumos-Developer] __FUNCTION__ in illumos
garrett at damore.org
Fri Dec 10 16:36:49 PST 2010
Is __func__ available in non-C99 mode?
I'd rather have this macro located in system headers somewhere (common),
than have delivered via cw. This would also allow for feature tests for
different compilers and different *modes* of the compilers. (E.g. don't
expose it except in C99 mode.)
On 12/10/10 04:11 PM, Albert Lee wrote:
> The non-standard __FUNCTION__ macro is not available in Sun Studio 12,
> the current compiler supported by illumos, although it is available in
> gcc and Sun Studio 12.1. It is equivalent to C99's __func__, which is
> available in Sun Studio 12.
> illumos is dependent on Net-SNMP headers (from SFW). illumos fails to
> build on OpenIndiana build 148 because of a build-time feature test in
> Net-SNMP that causes a generated header to use __FUNCTION__, where
> previously this was not the case: https://www.illumos.org/issues/495
> While the use of __FUNCTION__ can be removed from Net-SNMP, the
> references to __FUNCTION__ in illumos itself deserve a cleanup.
> __FUNCTION__ itself is defined in many headers in illumos as a
> compatibility measure for the headers themselves (which often have
> macros involving __FUNCTION___) or occasionally their consumers in ON.
> These definitions are wildly inconsistent (__func__, "", or another
> string) and would need to be revisited when we migrate to a newer
> compiler (even a non-Studio compiler).
> As __func__ is also used in existing code, it seems to be available
> throughout ON. I'm considering the approach of adding
> -D__FUNCTION=__func__ to cw and removing redefinitions of __FUNCTION__
> in any private headers. I would be lying if I said my main motivation
> wasn't to just work around the Net-SNMP breakage, but it seems like
> this would be a general improvement over the current situation.
> Does this sound reasonable to anyone?
> Developer mailing list
> Developer at lists.illumos.org
More information about the Developer