Logical Or Assignment Bug in ASC2

So, here’s something to keep an eye on if switching to AIR 3.8 (or 3.7 with the ASC2 compiler).

Last week at work we decided to finally make the jump from AIR 3.5 to AIR 3.8; something I was pretty excited about and had been looking forward to for awhile. After applying the update, though, I noticed some unit tests failing and sat down to investigate. Several places in our app, we map loaded xml files to data objects – a pretty common thing to do. In the parse methods we may use typical logical or assignment to fill properties with default values if they aren’t present in the xml. So it’s not uncommon to run across a line like this:

this.name = xml.@name || “Default Name”;

Now, in the ASC1 compiler this always worked fine. After switching to the ASC2 compiler in AIR 3.8, though, this is where our unit tests began falling down. In the case above, rather than assigning the “Default Name”, the name property was being assigned an empty string. So I decided to have a little look under the hood and see exactly what was going on. So here’s a real quick test class file I compiled to examine closer:

As you can see in the comments, compiling with ASC1, I got the results I was looking for and used to. In ASC2 though, I got an empty string. Using Adobe’s SWF Investigator, I decompiled the two swf files to the Actionscript Bytecode (ABC). With the ASC1, here is what’s going on at the point you try to get the xml’s name attribute:

Now, I’m no expert in ABC, but it’s easy enough to follow along with what’s happening. We get the property name from the xml and type it to a String (‘coerce_s’). Since there is no property ‘name’, that will be coerced to an empty String. We then convert that to a Boolean (‘convert_b’). Of course an empty string converted to a boolean is false so the ‘iftrue’ fails, we push the string “Default” on to the stack, type it as a string (‘coerce_s’), then set the local variable ‘name’ to that value.

Compiled in ASC2 though, we see a different story:

This time, we get the property name but do no coercion or conversion – we just wind up with an an untyped ‘something’. But an untyped ‘something’ is not a ‘nothing’, so the iftrue passes, we jump to the L1 block where we then coerce that ‘something’ into an empty string and set set the local variable ‘name’ to that.

So, we wind up with two very different results which may not be what you actually want. In this case, though, we only get an empty string where we may expect some default text. Worst case scenario, our app displays some blank text. Annoying, yeah, but not the end of the world.

But wait, it gets worse.

If you use logical or assignment with interfaces, things get really crazy. Here’s another test class file to test:

Let’s look at the byte code for ASC1 again.

We get our local ‘someArg’ variable, type it as an ITest object (‘coerce’), and convert that to a Boolean. Of course that boolean is true, so the ‘iftrue’ passes and we jump to the L1 block, type the variable to an ITest once again, set our local variable again, then do the trace.

But again, with the ASC2 compiler we see something very different:

Again, with ASC2 we get our local variable but do no coercion or conversion, so again we wind up with an ‘untyped something’. But, again, an ‘untyped something’ is not nothing, so the ‘iftrue’ passes and we jump to the L1 block. This time though, we still don’t coerce the ‘untyped something’ into an object and instead jump right into the trace statement and we see that our ‘untyped something’ is actually represented as an infinitesimally small number in memory (see the output comments in the actionscript above). But as you can see in the comments above, when we try to access properties of this ‘untyped something’ we wind up with a null object error.

As you can imagine, compared to the minor annoyance of an empty string, a null object error is a real ball deal breaker.

I’ve filed a bug report on this behavior with Adobe which you can check out here. In the meantime, though, if you’re making the jump into AIR 3.8 (or AIR 3.7 with the ASC2 compiler), I highly recommend avoiding using OR assignment like the plague.