[llvm-commits] [llvm] r172156 - /llvm/trunk/include/llvm/Support/Compiler.h

Joerg Sonnenberger joerg at britannica.bec.de
Fri Jan 11 06:50:53 PST 2013


On Fri, Jan 11, 2013 at 02:32:41PM +0200, Dmitri Gribenko wrote:
> On Fri, Jan 11, 2013 at 4:59 AM, Joerg Sonnenberger
> <joerg at britannica.bec.de> wrote:
> > On Fri, Jan 11, 2013 at 04:37:34AM +0200, Dmitri Gribenko wrote:
> >> On Fri, Jan 11, 2013 at 4:33 AM, Joerg Sonnenberger
> >> <joerg at britannica.bec.de> wrote:
> >> > On Fri, Jan 11, 2013 at 01:13:51AM -0000, Dmitri Gribenko wrote:
> >> >> Author: gribozavr
> >> >> Date: Thu Jan 10 19:13:51 2013
> >> >> New Revision: 172156
> >> >>
> >> >> URL: http://llvm.org/viewvc/llvm-project?rev=172156&view=rev
> >> >> Log:
> >> >> Add a new portability macro LLVM_FUNCTION_NAME, that expands to __func__, if
> >> >> supported.
> >> >>
> >> >> Modified:
> >> >>     llvm/trunk/include/llvm/Support/Compiler.h
> >> >
> >> > Why don't you add
> >> >
> >> > #if defined(_MSC_VER)
> >> > #define __func__ __FUNCTION__
> >> > #endif
> >> >
> >> > to config.h?
> >>
> >> Because __func__ should be defined as:
> >>
> >> static const char __func__[] = "function-name";
> >>
> >> Replacements available in other compilers might behave in a different
> >> way, thus we need a different name to avoid confusion.
> >
> > Eh, no. The main point is that you can't use __func__ in ways that
> > expect string merging, so "foo" __func__ "bar" doesn't work unlike e.g.
> > GCC's __FUNCTION__. __func__ can always be replaced by "" with minimal
> > lose of functionality.
> 
> I don't see how this contradicts what I said: available replacements
> might have different behavior.
> 
> Anyway, #define __func__ <anything> is UB since name __func__ is reserved.

Now you are silly. Yes, __func__ is a reserved macro name in C99. Point
is that Microsoft does not implement C99, so it is not reserved in their
dialect either. I am not aware of *any* compiler that implements
__func__ in a way that is incompatible with C99, so the easiest fallback
is to just define it for those that lack it.

Joerg



More information about the llvm-commits mailing list