Le 14/03/2011 14:05, Nick Treleaven a écrit :
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.
In gutils.h, it says that (as in your snippet) that glibconfig might already contain a definition that expands to va_copy() or __va_copy(), the implementations in gutils.h being fallback implementations if none of the above are found. IMHO it's probably better to use the system implementation -- but maybe custom implementation as in gutils.h are as good, don't know.
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.
Yeah, that's be at least interesting to see the GLib's developers POV on this.
Cheers, Colomban