From: Marcelo M. <mm...@ac...> - 2006-03-23 18:57:18
|
George Feinberg wrote: > > Thanks for your help, > >> sorry, I though you where defining SOME_CONSTANT >> using #define or so. >> >> hmmm, so, it is an enum, so, what is the declaration >> of the function that generates the error? > > > void setFlags(unsigned int flags); > > Yes, I know that this is not type-safe -- implicitly casting > an enumerated value to unsigned int. The values > are really flags constants. > > However, a quick test of > a change to declaring them const long in SWIG > indicates that the failure still happens. > > Using const unsigned int for constants appears to > work, so far. > > It just seems that the type checking in 1.3.29 (or whenever > it was introduced) is a bit inflexible regarding signed/unsigned > ints and casting. For myself, I'd be just as happy if the Tcl (or > Python) > versions of this interface would take something like, > setFlags(-56789), cast/treat the value as an unsigned int, and > just work. well, you can tell swig you want to do that, try %apply int {unsigned int flag}; ... void setFlags(unsigned int flags); Marcelo > > George > >> >> Marcelo >> >> George Feinberg wrote: >> >>> Marcelo, >>> >>> Thanks for the pointer, but I don' think it'll help this instance. >>> I should have been more clear. The SOME_CONSTANT is >>> coming from an explicitly assigned value in a C++ enum, e.g. >>> >>> enum { >>> SOME_CONSTANT = 0x80000000, >>> ... >>> } >>> >>> Enums are technically int, which is presumably why the >>> SWIG-generated code is using SWIG_From_int(). >>> >>> Since these enums are generating global symbols, >>> I guess I could change the declaration to be >>> const long SOME_CONSTANT=...; >>> >>> I'll give that a shot. >>> >>> Does the default constant type apply to enumerations as well? >>> >>> George >>> >>>> in the meantime, declare SOME_CONSTANT for swig as long, ie >>>> >>>> const long SOME_CONSTANT; >>>> >>>> I'll try to see if we can change the default constant type from >>>> int to long. >>>> >>>> Marcelo >>>> >>>> George Feinberg wrote: >>>> >>>>> >>>>> I am trying to start using release 1.3.29. My last release was >>>>> 1.3.25. >>>>> I'm running into a problem, and I'm hoping there's some >>>>> configuration >>>>> setting to address it. >>>>> >>>>> I am seeing this error in Tcl, but I believe it may affect Python >>>>> as well, >>>>> based on code reading. I have not generated other languages as yet. >>>>> Here's the error: >>>>> OverflowError in method 'foo', argument 2 of type 'unsigned int' >>>>> >>>>> I know why this is happening, based on walking the code paths. >>>>> Method foo takes an unsigned int as its second argument, >>>>> and the generated code type checks it using the method, >>>>> SWIG_AsVal_unsigned_SS_int(), which calls the method, >>>>> SWIG_AsVal_unsigned_SS_long(), which does this: >>>>> >>>>> if (Tcl_GetLongFromObj(0,obj, &v) == TCL_OK) { >>>>> if (v >= 0) { >>>>> if (val) *val = (long) v; >>>>> return SWIG_OK; >>>>> } else { >>>>> return SWIG_OverflowError; >>>>> } >>>>> >>>>> In this case, the "unsigned int" passed happens to >>>>> be the string "-2147483648". This issue is that this >>>>> value comes from a constant (enumeration) in my code >>>>> that has the integer value 0x80000000 (a flag). >>>>> >>>>> This assignment happens in the initialization code, which does this: >>>>> SWIG_Tcl_SetConstantObj(interp, "SOME_CONSTANT", SWIG_From_int >>>>> (static_cast< int >(SOME_CONSTANT))); >>>>> >>>>> I don't *think* the problem is the fact that the constant becomes >>>>> "negative." >>>>> That's fine with me, as long as the internal casting works; >>>>> however it does not. >>>>> >>>>> It appears to me that the bug, if there is one, is in the fact >>>>> that SWIG_AsVal_unsigned_SS_long is getting a *signed* value >>>>> (Tcl_GetLongFromObj()) and comparing it to 0 to determine validity. >>>>> This is not the way to find overflow for an unsigned int. >>>>> >>>>> Any ideas/fixes out there? >>>>> >>>>> Thanks, >>>>> >>>>> George >>>> > |