[ASC] inline XML->String->Boolean evaluates incorrectly inside an if condition

VERIFIED INVALID

Status

Tamarin
Virtual Machine
P2
major
VERIFIED INVALID
9 years ago
9 years ago

People

(Reporter: Chris Peyer, Assigned: Jeff Dyer)

Tracking

unspecified
flash10.1
x86
All
Bug Flags:
flashplayer-qrb +

Details

(Reporter)

Description

9 years ago
Steps to reproduce:

var str:String = (<x />).@foo;
if(str){
  trace("foo exists");
}else{
  trace("empty");
}

var str2:String;
if((str2 = (<x />).@foo)){
  trace("foo exists");
}else{
  trace("empty");
}

Actual Results:
 
empty
foo exists
 
 Expected Results:
 
empty
empty
 

Transferred Comments:

Chris Peyer - Thu Aug 13 16:25:39 PDT 2009
Valid, but obscure bug:

var x;
trace(Boolean(x='a string')); // true
trace(Boolean(x=true)); // true
trace(Boolean(x='')); // false
trace(Boolean(x=false)); // false

(<x />).@foo should evaluate to '' (empty string) which should then evaluate to false 


This bug transferred from: http://bugs.adobe.com/jira/browse/ASC-3763
(Reporter)

Updated

9 years ago
Flags: in-testsuite?
Flags: flashplayer-qrb?

Updated

9 years ago
Priority: -- → P2
Target Milestone: --- → flash10.1

Updated

9 years ago
Assignee: nobody → lhansen

Comment 1

9 years ago
This appears to be an ASC bug.

Slightly rewritten the test case is this:

package {

    function f() {
	var str:String = (<x />).@foo;
	if(str)	 
	    return "foo exists 1";
	else
	    return "empty 1";
    }

    function g() {
	var str2:String;
	if((str2 = (<x />).@foo))
	    return "foo exists 2";
	else
	    return "empty 2";
    }
    print(f());
    print(g());

}

Now we can examine the disassembly for f and g.  I've removed some extraneous parts:

function f()

  2         findpropstrict	XML
  4         getproperty   	XML
  6         pushstring    	"<x/>"
  8         construct     	(1)
  10        getproperty   	foo

  12        coerce_s      	
  13        setlocal1     	
  14        getlocal1     	
  15        convert_b     	
  16        iffalse       	L1


function g()

  5         findpropstrict	XML
  7         getproperty   	XML
  9         pushstring    	"<x/>"
  11        construct     	(1)
  13        getproperty   	foo

  15        dup           	
  16        setlocal2     	
  17        coerce_s      	
  18        setlocal1     	
  19        getlocal2     	
  20        kill          	2
  22        convert_b     	
  23        iffalse       	L1

Observe that in the case of f (the correctly working case) the result of the ".@foo" reference is first converted to string, then that value is used.  In the case of g, the unconverted value is tucked away before the conversion and later reused for the boolean comparison; at that point it's an object value and hence does not become false.

Looks like a bug in code generation in ASC.  Don't know if it's triggered by something strange around ".@foo" or if it's a common problem having to do with assignment in a condition.
Assignee: lhansen → jodyer
Summary: inline XML->String->Boolean evaluates incorrectly inside an if condition → [ASC] inline XML->String->Boolean evaluates incorrectly inside an if condition

Comment 2

9 years ago
reopened http://bugs.adobe.com/jira/browse/ASC-3763
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → INVALID
(Reporter)

Updated

9 years ago
Status: RESOLVED → VERIFIED
(Reporter)

Comment 3

9 years ago
asc bug, testmedia will have to be created for that bug.
Flags: in-testsuite?
Flags: flashplayer-qrb?
Flags: flashplayer-qrb+
You need to log in before you can comment on or make changes to this bug.