Re: [Swig-devel] Perl type conversion regression: string not converted to integer

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

hmm, good question, we will need to discuss this a little more:

to recall the problem, we have:

     typedef unsigned char  t_u8;
     typedef t_u8           t_bool;
     int SetBool(t_bool b);

 and in 1.3.27 this work:

     $r = test::SetBool("0");

ie, "0" is implicitely coerced to 0, but in 1.3.28 it fails since the
argument is recognized to be a non-integer type. Note that this is the
same behavior now for perl, python, tcl and ruby.

In 1.3.27 there was no type checking for this case,
the code was executed as

        arg1 = (t_bool) SvUV(ST(0));

which forces coercion with no checking. Note than in 1.3.27
calling
         
         SetBool("l")  or SetBool("1")

where both accepted, but the results were different, assigning the
variable to '0' and '1', respectively. If you don't see the difference,
the first call uses lower case L, the second uses the number '1'.

In 1.3.28,  extra SvUOK and/or SvIOK are performed before doing
the conversion, hence SetBool("1") or SetBoll("l") always
fail, while SetBool(0)/SetBool(1) work as expected.

I am not sure what is the "expected" behavior, the 1.3.27 was
a "relaxed" behavior, with some unexpeted results,
while 1.3.28 is more closer to C++, but when it works, or fails,
is consistent.

Whatever we decide, we should discuss what we expect in this case:

        int foo(unsigned int uval);
        int foo(const char *msg);

so, we need to consider the following cases (at least):

             foo(1)          -> call foo(unsigned int)
             foo("1")      ->  ?
             foo("l")      ->  ?
             foo("hello") -> call foo(const char*)

So, the final question is, is this an error in 1.3.28, or it is a fix
and it was broken in 1.3.27?

Please discuss....

Marcelo


John Koleszar wrote:

> There seems to be a bug in the CVS version when creating perl 
> bindings. Version 1.3.27 was able to implicitly convert strings to 
> integers (eg "1" -> 1), but 1.3.28 dies with a TypeError. I think the 
> problem is in SWIG_AsVal_unsigned_SS_long, since neither SvUOK or 
> SvIOK is true. Is there another macro that should be used as a "can 
> this sv be coerced into being a uv?" I didn't look at the 1.3.27 
> version of this function, but I don't really know anything about perl 
> internals either, so I figured I'd ask the list.
>
> John
>
> === test.i ===
> %include "typemaps.i"
> %module test
> %{
> typedef unsigned char  t_u8;
> typedef t_u8           t_bool;
> static t_bool priv_bool = 0;
>
> int GetBool(t_bool *b) {
>    *b=priv_bool;
>    printf("C: Returning %d\n",*b);
>    return 0;
> };
>
> int SetBool(t_bool b) {
>    printf("C: Setting %d\n",b);
>    priv_bool = b;
>    return 0;
> };
>
> %}
>
> %apply unsigned char *OUTPUT { unsigned char * }
>
> typedef unsigned char  t_u8;
> typedef t_u8           t_bool;
> int GetBool(t_bool *b);
> int SetBool(t_bool b);
>
> === test_pl.pl ===
> #!/usr/bin/perl
> use test;
>
> $r = test::SetBool(1);
> print "Set Result: $r\n";
> $r = test::GetBool();
> print "Get Result: $r\n";
> $r = test::SetBool("0");
> print "Set Result: $r\n";
> $r = test::GetBool();
> print "Get Result: $r\n";
>
>
> === example output ===
> C: Setting 1
> Set Result: 0
> C: Returning 1
> Get Result: 1
> TypeError in argument 1 of type 't_bool'
> swig/perl error at ./test_pl.pl line 8.
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log 
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> Swig-devel mailing list
> Swi...@li...
> https://lists.sourceforge.net/lists/listinfo/swig-devel