[Geany-devel] G_VA_COPY problem

Colomban Wendling 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
>>> 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



More information about the Devel mailing list