[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