Compile warning in our perl plugin

Etan Reisner pidgin at unreliablesource.net
Mon Feb 8 08:27:18 EST 2010


On Sat, Feb 06, 2010 at 03:46:17PM -0800, Mark Doliner wrote:
> I get this warning when compiling our perl plugin:
<snip long warning message>
> It happens because we pass a "va_list args" to a function expecting
> "va_list *args"  It looks like purple_perl_sv_from_vargs() takes a
> pointer to a va_list because we're afraid that maybe on some systems
> va_list can't be passed around as-is.  And so we have a complicated
> check in configure.ac to determine whether a va_list can be passed by
> value, and we set the VA_COPY_AS_ARRAY define.  See this ticket for
> background info: http://developer.pidgin.im/ticket/7404
<snip>
> --Mark

purple_status_type_new_with_attrs doesn't itself get passed a va_list,
while perl_signal_cb does, I imagine that may be material here.

I think at the time I fixed the problem I considered wrapping the function
definition/declaration in an ifdef to match the call site but wasn't sure
that was necessary (and the minimal fix seemed to work). (Also a
conditionally argumented function sounded like a horrible idea to me.)

I've got no objections to the change assuming you test it on systems that
were known to have problems before I fixed it (that is test both sides of
the ifdef). Do we know it will actually makes things better on both ends?
(As I recall the other side of the coin actually uses 'va_list *'.)

On the other hand it looks like we may be able to use G_VA_COPY (like
signals.c:purple_signal-emit_vargs does) to work around this. In which
case that might just be the best solution. I'm not sure why I didn't look
into that in the first place.

    -Etan




More information about the Devel mailing list