[Swig-devel] [ swig-Bugs-1481958 ] [Perl] Unsigned long constants handled incorrectly in 1.3.29

[SourceForge.net <no...@so...>]

Bugs item #1481958, was opened at 2006-05-04 16:01
Message generated for change (Settings changed) made by talby
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=1481958&group_id=1645

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: perl
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: mas (asmak)
Assigned to: Robert Stone (talby)
Summary: [Perl] Unsigned long constants handled incorrectly in 1.3.29

Initial Comment:
SWIG version is 1.3.29.

The simple code below produces different results on
ActivePerl 5.8.8, Linux Perl 5.8.0 and Cygwin Perl 5.8.7.

ActivePerl produces correct result.
Cygwin's one produces "OverflowError in method
'param2', argument 1 of type 'unsigned long'".
Linux one produces result of 0 instead of 4294967295.

# cat example.i
%module example

%inline %{
#define ULONG_CONSTANT 0xFFFFFFFFU

unsigned long param2(unsigned long param) {
  return param;
}
%}

# cat runme.pl
use example;
print "example::param2: " .
example::param2($ULONG_CONSTANT) . "\n";


----------------------------------------------------------------------

Comment By: Robert Stone (talby)
Date: 2011-09-11 01:10

Message:
I've put some time into this, and committed r12802 to trunk.  I think the
primary issue was that the typemaps didn't seem to be aware that SvIOK(sv)
returns true for a UV that is larger than IV_MAX.  This was actually news
to me too.  I've set up better testcases around the integer boundaries and
retooled the typemaps to be more cautious.

----------------------------------------------------------------------

Comment By: Torsten Landschoff (torsten)
Date: 2011-08-19 21:34

Message:
I just uploaded a patch to
https://sourceforge.net/tracker/?func=detail&aid=3394784&group_id=1645&atid=301645
as it seems I can not attach files here. :-(


----------------------------------------------------------------------

Comment By: Olly Betts (olly)
Date: 2007-03-05 03:13

Message:
Logged In: YES 
user_id=14972
Originator: NO

Sorry, I'm not sure how (or if) you can override an individual macro in
the UTL stuff.  Try asking on the mailing list.

----------------------------------------------------------------------

Comment By: Nik Clayton (nikclayton)
Date: 2007-03-03 18:05

Message:
Logged In: YES 
user_id=189581
Originator: NO

That would work.

While we wait for an official fix, is there an easy way for third party
projects that use Swig to override this locally?  Specifically, I'm
thinking of Subversion, where I've just bumped in to this problem as I
expand the Subversion Perl bindings.  I'd like to get a local fix in to the
Subversion tree now (so that we don't need to be dependent on your release
schedule), but I'm not sure how best to make the fix.

I tried copy/pasting the affected code from perlprimtypes.swg in to one of
our .i files, but that didn't seem to have an effect on the code generated
by Swig.

----------------------------------------------------------------------

Comment By: Olly Betts (olly)
Date: 2007-03-03 17:55

Message:
Logged In: YES 
user_id=14972
Originator: NO

Nik: That makes the test for v >= 0 redundant though, so we no longer
check for trying
to set an unsigned variable to a negative value.  But if Perl is really
losing track of
the signed/unsigned nature of the value, then we can't reliably check for
that here anyway,
so perhaps this is the best answer (which is pretty much what asmak had):

SWIG_AsVal_dec(unsigned long)(SV *obj, unsigned long *val) 
{
  if (SvUOK(obj)) {
    if (val) *val = SvUV(obj);
    return SWIG_OK;
  } else if (SvIOK(obj)) {
    /* Many Perl ports apparently lose track of the unsigned/signed nature
of a scalar value. */
    if (val) *val = (unsigned long)SvIV(obj);
    return SWIG_OK;
  } else {
  .....

----------------------------------------------------------------------

Comment By: Nik Clayton (nikclayton)
Date: 2007-03-03 17:26

Message:
Logged In: YES 
user_id=189581
Originator: NO

A better fix might be:

SWIG_AsVal_dec(unsigned long)(SV *obj, unsigned long *val) 
{
  if (SvUOK(obj)) {
    if (val) *val = SvUV(obj);
    return SWIG_OK;
  } else  if (SvIOK(obj)) {
    unsigned long v = SvIV(obj);  /* addition of "unsigned" here */
    if (v >= 0) {
      if (val) *val = v;
      return SWIG_OK;
    } else {
      return SWIG_OverflowError;
    }
  } else {
  .....

----------------------------------------------------------------------

Comment By: mas (asmak)
Date: 2007-01-17 10:08

Message:
Logged In: YES 
user_id=1516722
Originator: YES

AFAIU the problem is that most Perl ports lose tracking of the unsigned
flag of a numeric value, so for the 0xFFFFFFFFU constant internal Perl var
contains -1. So SvUOK() doesn't work, only SvIOK() does. 
I made a dirty workaround for myself, patching perlprimtypes.swg:

SWIG_AsVal_dec(unsigned long)(SV *obj, unsigned long *val) 
{
  if (SvUOK(obj)) {
    if (val) *val = SvUV(obj);
    return SWIG_OK;
  } else  if (SvIOK(obj)) {
    long v = SvIV(obj);
//    if (v >= 0) {
      if (val) *val = v;
      return SWIG_OK;
/*    } else {
      return SWIG_OverflowError;
    }
*/
  } else {
.....

Please note that SWIG_AsVal_dec(unsigned long long) may require the same
modification in SWIG-1.3.31.

Hope this helps investigating this bug.


----------------------------------------------------------------------

Comment By: Olly Betts (olly)
Date: 2006-09-25 01:57

Message:
Logged In: YES 
user_id=14972

Thanks for your bug report.

I've done some investigating, but don't yet fully understand
what is going on.  I'll continue to dig.

Incidentally, a simpler testcase seems to be:

use example;
print "$example::ULONG_CONSTANT\n";

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=1481958&group_id=1645