From: "Johnson, Lyle" <LJohnson@...>
Date: 2002-02-16T02:33:03+09:00
Subject: RE: [Swig] RE: SWIG/Ruby woes with g++ 3.0

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

Craig, you're absolutely right; I'll get this fixed ASAP. Good freaking
grief, I wish Matz could make some attempt to be consistent. At least
appears RUBY_METHOD_FUNC *appears* to mean something for Ruby 1.7; it looks
like it's completely meaningless for Ruby 1.6, so I'm not sure why it's even
there. I wonder if this is what it was like before Python went to ANSI C
declarations?

Sorry for the rant. Before I check this in, could you please help me confirm
that the following set of definitions for VALUEFUNC and VOIDFUNC (in
rubyhead.swg) would work properly for both Ruby 1.6 and 1.7? I really need
another pair (or pairs) of eyes to make sure this covers all the bases:

    #ifdef __cplusplus
    #  ifndef RUBY_METHOD_FUNC /* These definitions should work for Ruby
1.4.6 */
    #    define VALUEFUNC(f) ((VALUE (*)()) f)
    #    define VOIDFUNC(f)  ((void (*)()) f)
    #  else
    #    ifndef ANYARGS /* These definitions should work for Ruby 1.6 */
    #      define VALUEFUNC(f) ((VALUE (*)()) f)
    #      define VOIDFUNC(f)  ((RUBY_DATA_FUNC) f)
    #    else /* These definitions should work for Ruby 1.7 */
    #      define VALUEFUNC(f) ((VALUE (*)(ANYARGS)) f)
    #      define VOIDFUNC(f)  ((RUBY_DATA_FUNC) f)
    #    endif
    #  endif
    #else
    #  define VALUEFUNC(f) (f)
    #  define VOIDFUNC(f) (f)
    #endif

Thanks,

Lyle