GNOME Bugzilla – Bug 51639
Equivalent of __FUNCTION__ for Sun's compiler
Last modified: 2011-02-18 16:07:08 UTC
glib.h uses __FUNCTION__ and __PRETTY_FUNCTION__ when compiling with gcc. Attached patch adds the same functionality when compiling with Sun's 6.1 compiler. I think the functionality exists in version 6.0, so the test in that case should be __SUNPRO_C >= 0x510, but I don't have that version, so I'm unable to check. The patch modifies file gstrfuncs.c because Sun's compiler doesn't want to paste strings and __func__. Since that operation works perfectly fine with __FILE__ and __LINE__, I suppose it's a bug in the compiler. I'll see what I can do about it, but for now gstrfuncs.c has to be modified. And now let's see if Bugzilla will let me attach a file to this report...
Created attachment 361 [details] [review] Promissed patch
As I recall, the C99 __func__ is defined to be equivalent to extern const char *__func__; So, no, it isn't a bug that it won't token paste. (I don't know the rational for why it was different from __FILE__, __LINE__) But since it has different semantics, it can't simply be used to implement G_GNUC_PRETTY_FUNC. So, I think you need to: a) Redo the patch against glib-1.3, since a patch like this won't be accepted for glib-1.2 b) Use a different name (G_PRETTY_FUNC()? G_FUNC_NAME()?) glib-1.3 also contains a macro G_STRLOC which combines __PRETTY_FUNC__, __FILE__, __LINE__), but I don't think there is much you can do about that with the semantics of __func__.
We might, in the future, want to add some addition so that we can make g_return_if_fail() fall back to __func__ if __PRETTY_FUNCTION__ isn't there; I don't think a modification of an existing API to work in terms of __func__ works.
I'll attach the patch I'm currently using with glib 1.2.10. It doesn't change the API, I think. The version check for 0x520 is conservative. I think it would work on 0x510 as well, but I don't have that version to test.
Created attachment 6186 [details] [review] The new patch with __func__
* On some reflection, I think G_FUNCTION_NAME would be better than G_PRETTY_FUNC. * I hate the SUNPRO version checks. I think it should be pretty easy to come up with a test for G_HAS_C99_FUNC in configure.in.
Tim Recently committed: Thu Nov 27 17:04:08 2003 Tim Janik <timj@gtk.org> * glib/gmacros.h: defined G_STRFUNC, which (pretty) prints the current function (since G_STRLOC and G_GNUC_*FUNCTION became unusable with gcc-3.0). Don't like the name as well as G_FUNCTION_NAME, but good enough.