[Geany-devel] G_VA_COPY problem
lists.ban at xxxxx
Mon Mar 14 13:11:05 UTC 2011
Le 14/03/2011 14:05, Nick Treleaven a écrit :
> On Sat, 12 Mar 2011 15:46:59 +0100
> Colomban Wendling <lists.ban at 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
>>> * 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
More information about the Devel