ugh. G_STRFUNC is outputting different text ("gboolean g_markup_parse_context_end_parse(GMarkupParseContext
*, GError **)" rather than just "g_markup_parse_context_end_parse", so the g_test_expect_message() is failing.

Need to figure out if there's someway we can make this be consistent across platforms/compilers or if we need to just make the expectations less strict.

what compiler are you using exactly? And what does this output:

  #include <stdio.h>

  int
  main (int argc, char **argv)
  {
    printf ("__FUNCTION__ is %s\n", __FUNCTION__);
    printf ("__PRETTY_FUNCTION__ is %s\n", __PRETTY_FUNCTION__);
    printf ("__func__ is %s\n", __func__);
    return 0;
  }


More generically, what do people think about this issue? It could be worked around in the test expectations easily enough:

   g_test_expect_message (G_LOG_DOMAIN, G_LOG_LEVEL_CRITICAL,
-                         "g_markup_parse_context_end_parse: assertion 'context->state != STATE_ERROR' failed");
+                         "*g_markup_parse_context_end_parse*assertion 'context->state != STATE_ERROR' failed");

and we can document in g_test_expect_message() that you should do that

OS X 10.8 with Apple's XCode-4.6.2, and your program foo.c...


$ clang -v
Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)
Target: x86_64-apple-darwin12.4.0
Thread model: posix

$ clang foo.c -o foo

$ ./foo
__FUNCTION__ is main
__PRETTY_FUNCTION__ is int main(int, char **)
__func__ is main


$ llvm-gcc -v
Using built-in specs.
Target: i686-apple-darwin11
Configured with: /private/var/tmp/llvmgcc42/llvmgcc42-2336.11~182/src/configure --disable-checking --enable-werror --prefix=/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2 --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-prefix=llvm- --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin11 --enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2336.11~182/dst-llvmCore/Developer/usr/local --program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11 --target=i686-apple-darwin11 --with-gxx-include-dir=/usr/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)

$ llvm-gcc foo.c -o foo

$ ./foo
__FUNCTION__ is main
__PRETTY_FUNCTION__ is main
__func__ is main

Created attachment 246814 [details] [review]
Make G_STRFUNC consistent across platforms

Recent versions of clang have changed __PRETTY_FUNCTION__ to always
include the function signature (rather than including the function
signature in C++ but not in C like gcc does). This causes G_STRFUNC to
give different results under clang and gcc, causing some tests with
g_test_expect_messages() to fail.

Fix this by only using __PRETTY_FUNCTION__ in C++, and using
__FUNCTION__ in C. (Under gcc this change has no effect.)

Review of attachment 246814 [details] [review]:

ok

Still fails same way.

Attachment 246814 [details] pushed as b7b3838 - Make G_STRFUNC consistent across platforms

So the patch I said did *not* fix it was pushed and then this bug closed as FIXED??

Anyway, it's still exactly as broken in 2.38.2. From glib/tests/markup-collect.log:

(/sw/build.build/glib2-shlibs-2.38.2-1/glib-2.38.2/glib/tests/.libs/markup-collect:34156): GLib-CRITICAL **: Did not see expected message CRITICAL **: g_markup_parse_context_end_parse: assertion 'context->state != STATE_ERROR' failed
# GLib-FATAL-CRITICAL: gboolean g_markup_parse_context_end_parse(GMarkupParseContext *, GError **): assertion 'context->state != STATE_ERROR' failed

(/sw/build.build/glib2-shlibs-2.38.2-1/glib-2.38.2/glib/tests/.libs/markup-collect:34156): GLib-CRITICAL **: gboolean g_markup_parse_context_end_parse(GMarkupParseContext *, GError **): assertion 'context->state != STATE_ERROR' failed
../../tap-test: line 5: 34156 Trace/BPT trap: 5       $1 -k --tap

a patch would help

Found it. The committed b7b3838 does work for the G_STRFUNC macro it fixed, but the test is failing due to one of the g_return_* macros, which hardcode __PRETTY_PRINT__ rather than using the (now fixed) one internally...

...and seems fixed in git via 172aaa3a (in particular: Bug  711047, comment 52).