From: Craig Files <cfiles@...>
Date: 2002-02-15T23:44:44+09:00
Subject: Re: [Swig] RE: SWIG/Ruby woes with g++ 3.0

Lyle, 

  I don't think that this is fixed yet.  (I attempted to email you about this
on Wednesday, and it looks like I sent it to the wrong address.  So, if you
have changed the code since then please let me know.)

  I just downloaded the latest CVS swig version.  This is what rubyhead.swg
looks like:
#ifdef RUBY_METHOD_FUNC
#  define VALUEFUNC(f) RUBY_METHOD_FUNC(f)
#  define VOIDFUNC(f) ((RUBY_DATA_FUNC) f)
#else
#  ifdef __cplusplus
#    if defined(_WIN32) && defined(_MSC_VER)
#      define VALUEFUNC(f) ((VALUE (*)())f)
#      define VOIDFUNC(f) ((void (*)(void *))f)
#    else
#      define VALUEFUNC(f) ((VALUE (*)(...))f)
#      define VOIDFUNC(f) ((void (*)(...))f)
#    endif
#  else
#   define VALUEFUNC(f) (f)
#   define VOIDFUNC(f) (f)
#  endif
#endif

I am compiling with g++ version 3.02 and version 2.96*.  The problem is that
this code works for Ruby 1.7, but not for Ruby 1.6.  What I see is that
VALUEFUNC(f) is now incorrect.

In ruby 1.6:
#define RUBY_METHOD_FUNC(func) ((VALUE (*)__((...)))func)
and in ruby 1.7
#define RUBY_METHOD_FUNC(func) ((VALUE (*)(ANYARGS))func)

The surprise is that methods like rb_define_singleton_method are hard coded
defined in ruby 1.6 as this:
void rb_define_singleton_method _((VALUE,const char*,VALUE(*)(),int));

While in ruby 1.7:
void rb_define_singleton_method _((VALUE, const char*, VALUE(*)(ANYARGS),
int));
Anyway, because of the difference in definitions in ruby 1.6, the current swig
wrapper is not working.

  Craig

On Fri, Feb 15, 2002 at 07:49:40AM -0600, Johnson, Lyle wrote:
> > 	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.
> >
> > 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
> > 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?
> 
> This has been fixed in the CVS version of SWIG (and presumably will show up
> in the SWIG 1.3.12 release). In the CVS version of SWIG 1.3, VALUEFUNC() is
> just an alias for RUBY_METHOD_FUNC(), which is the macro that Matz uses in
> "ruby.h" to do this typecase; so SWIG-generated wrappers *should* now always
> be consistent with the Ruby header files against which you're compiling.
> _______________________________________________
> Swig maillist  -  Swig@cs.uchicago.edu
> http://mailman.cs.uchicago.edu/mailman/listinfo/swig

-- 
_____________________________________________________________________
 Craig Files                      |                     / 
   http://www.ee.pdx.edu/~cfiles/ |          __o       / 
   craig_files@agilent.com        |          \<,      / 
__________________________________| _______()/ ()____/ (970)288-0183