On Sat, 12 Mar 2011 15:46:59 +0100 Colomban Wendling lists.ban@herbesfolles.org wrote:
practice, fair enough. But the way I see it, GLib could have left this until compile time with gutils.h:
/* Define G_VA_COPY() to do the right thing for copying va_list variables.
- glibconfig.h may have already defined G_VA_COPY as va_copy or
__va_copy. */ #if !defined (G_VA_COPY) ...
I'm not sure it is really possible to check whether va_copy(), __va_copy() (or whatever) works correctly at compile-time, since it's not necessarily a macro.
I wasn't clear. The code I quoted already is in gutils.h. That's why removing the definition from glibconfig.h works - it is possible to do this at compile time, check the file.
I'm not convinced there is an ABI problem with -ansi here because C99 may be ABI compatible with ANSI C. The -ansi switch just tells the compiler not to allow using va_copy, it does exist in the glibc library.
Agree, the only problem here is that GLib did some checks when it was configured and the function no longer exists in your build, but it won't be an ABI problem.
Anyway, I've #undef'd G_VA_COPY from my system glibconfig.h and everything seems OK again, no link errors.
If you prefer I can easily add a #if NO_G_VA_COPY in the code (that would switch to a g_strdup_vprintf()-based implementation) so somebody wanting to build with ANSI only need to define it -- and we might could event do this automatically at configure time.
I'm not sure. I probably should raise this with the GLib team.
Regards, Nick