#766 %applying typemaps to enum types

[Petr Novotny]

I process this interface file with SWIG 1.3.29 with -
c++ -perl:
--
%module bug;
enum Test { X,Y,Z };
%include "typemaps.i"
%apply int *OUTPUT { Test &out };
void test(Test &out);
--

The result is surprising: In test() function, Test is
considered an output argument, but it is wrapped as
SWIGTYPE_p_Test, not returned as an integer. (It
doesn't change if I say "enum Test &out" or if I
say "int &OUTPUT".) It shows that the %apply is not
ignored (without it, Test & is wrapped as in *input*
pointer, not an argout pointer) but the body of the
typemap is...

When I create an explicit %typemap(in) and %typemap
(argout) for Type &out, all works fine.

I expected to be able to tell swig, "enum looks like
an int so treat it like an int". Was my expectation
wrong?

[Petr Novotny]

Logged In: YES
user_id=1631419

Seems to be a symptom of 1592239.

[William Fulton]

Your SWIG code is fine. A snippet from generated code looks like this to me in swig-2.0.1:

if (SWIG_IsTmpObj(res1)) {
if (argvi >= items) EXTEND(sp,1); ST(argvi) = SWIG_From_int SWIG_PERL_CALL_ARGS_1((*arg1)); argvi++ ;
} else {
int new_flags = SWIG_IsNewObj(res1) ? (SWIG_POINTER_OWN | 0) : 0;
if (argvi >= items) EXTEND(sp,1); ST(argvi) = SWIG_NewPointerObj((void*)(arg1), SWIGTYPE_p_Test, new_flags); argvi++ ;
}

So it can get treated as an integer and if you debug this you'll find it is. Using this perl code:
$c = example::test();
print "c: $c\n";

However, if you are unhappy with the generated code, you can use your own typemaps. Incidentally, you can use the swig -debug-tmused option to see which typemaps are being used and then look at the preprocessed output (using swig -E) to find the exact typemap (note that there is a chance of having more than one typemap with the same).