From: Paul Brannan <paul@...>
Date: 2002-02-16T00:22:21+09:00
Subject: Re: SWIG/Ruby woes with g++ 3.0

On Fri, Feb 15, 2002 at 06:11:58PM +0900, Luigi Ballabio wrote:
> 
> Greetings,
> 	I just found a problem with generated SWIG code and g++ 3.0.3 which 
> escaped me until now since I've been using 2.95.4.

What is 2.95.4?  The latest 2.95 version listed on gcc.gnu.org is
2.95.3.

> 
> In short:
> 1) the SWIG/Ruby wrappers define VALUEFUNC(f) as (VALUE (*)(...))f when 
> __cplusplus is defined.
> 2) in the initialization function, VALUEFUNC(f) is passed to 
> rb_define_method as the 3rd argument
> 3) However, in intern.h rb_define_method is declared as taking a 3rd 
> argument of type VALUE (*)(), i.e., no ellipsis

Hmm, rb_define_method is in ruby.h on Ruby 1.6.5.  What version of Ruby
are you using?

> 4) g++ 2.95.4 didn't complain. g++ 3.0.3 does. It says that it "cannot 
> convert 'VALUE (*)(...)' to 'VALUE (*)()'" and fails.
> 
> Any insight? Is this something that can be fixed?

It is a bug in Ruby, not in SWIG.

In C, Foo(*)() indicates a pointer to a function that returns a Foo and
takes an unspecified number of arguments.  Note that this is an
obsolescent feature of the language, and in C++, Foo(*)() has been
changed to indicate a pointer to a function that returns a Foo and takes
no arguments.

The tricky part comes when the function being called is declared as
extern "C".  Gcc 2.95.x treats such a function C-style; gcc 3.0.x treats
it C++-style.

The correct solution is to fix the Ruby headers to for the functions to
take (...) if __cplusplus is defined.  I believe this has been done in
Ruby 1.7.

However, if you cannot move to Ruby 1.7, then try adding the following
to your swig file:

  %{
  #define rb_define_method(klass, name, func, params) \
          rb_define_method(klass, name, (VALUE(*)(...))(func), params)
  %}

(I haven't tested this, since I'm still using a very old version of
swig, so let me know if this doesn't work).

Paul