[Geany-devel] G_VA_COPY problem

Nick Treleaven nick.treleaven at xxxxx
Mon Mar 14 13:05:02 UTC 2011


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.

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



More information about the Devel mailing list