The same enumeration items wraps in a constants of different types in SWIG > 2.0.1

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

The same enumeration items wraps in a constants of different types in SWIG > 2.0.1

johonde
This post has NOT been accepted by the mailing list yet.
This post was updated on .
I find a little bug in SWIG 3.0.12. If you make little changes in file examples/python/enum/example.h, just add a char constant to the one of enum item (g):
enum color { RED, BLUE, GREEN = 'g'};

And then make a wrap, compile _example.so and run $python runme.py, you will get:
enter code here
*** color ***
RED    = 0
BLUE   = 1
GREEN  = g

*** Foo::speed ***
Foo_IMPULSE   = 0
Foo_WARP      = 1
Foo_LUDICROUS = 2

Testing use of enums with functions

color = RED, speed = IMPULSE speed
color = BLUE, speed = WARP speed
Traceback (most recent call last):
  File "runme.py", line 22, in <module>
    example.enum_test(example.GREEN, example.Foo.LUDICROUS)
TypeError: in method 'enum_test', argument 1 of type 'color'
It is strange situation, isn't it? The same enumeration items wraps in a constants of different types and the poor little function waits just one type of enum constant (now it waits ints, but GREEN constant type is char). How it can be bypassed without rollback SWIG version, what do you think?

This bug appears in SWIG 3.0.12, 3.0.11, but in 2.0.1 all works fine.