Re: [Swig-user] type checking in 1.3.29

[Marcelo M. <mm...@ac...>]

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?

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
>>>
>>>
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.Net email is sponsored by xPML, a groundbreaking scripting 
>>> language
>>> that extends applications into web and mobile media. Attend the live 
>>> webcast
>>> and join the prime developer group breaking into this new coding 
>>> territory!
>>> http://sel.as-us.falkag.net/sel? 
>>> cmd=lnk&kid=110944&bid=241720&dat=121642
>>> _______________________________________________
>>> Swig-user mailing list
>>> Swi...@li...
>>> https://lists.sourceforge.net/lists/listinfo/swig-user
>>
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by xPML, a groundbreaking scripting 
>> language
>> that extends applications into web and mobile media. Attend the live 
>> webcast
>> and join the prime developer group breaking into this new coding 
>> territory!
>> http://sel.as-us.falkag.net/sel? 
>> cmd=lnk&kid=110944&bid=241720&dat=121642
>> _______________________________________________
>> Swig-user mailing list
>> Swi...@li...
>> https://lists.sourceforge.net/lists/listinfo/swig-user
>
>