I last talked about unknown values and how they work in expressions, but what happens when an unknown value is passed to a conditional statement? Let’s say you try to do:

var x = new Date();
if (x < new Date(2013, 3, 12)) {
    console.log('It is before April 12th, 2013');
} else {
    console.log('It is on or after April 12th, 2013');
}

What should happen here? From an analysis perspective, both branches will be run at some point in time by someone, so it makes sense to analyze both branches and this is exactly what the code processor does. In general, anytime a decision needs to be made on whether or not a block of code needs to be executed and that decision is based on an unknown value, that code is executed.

This raises the question of course, what happens when statements inside of this code block affect code outside of the block? For example:

var x = 10;
if (new Date()) {
    x += 10;
}
console.log(x);

What should the value of x be when it is logged to the console? Since it depends on how the actual code will be executed on device, the answer is that we don’t know and so I set x to unknown. Since code processor has to treat assignments (and related operations) differently inside of the block than it does outside of the block, the code processor flags the block as ambiguous.

There are further rules and restrictions when dealing with these ambiguous blocks. What happens when a return statement is encountered inside of an ambiguous block? In this case, the code processor marks the function as having an unknown return value, stops evaluating the block, and continues outside the block. Semantically, the return behaves as if it were a break statement inside a loop block. The rest of the function is evaluated, and then unknown is returned. Similar, but a lot more tricky, is throw statements; honestly I haven’t figured this one out yet.

My examples so far have all been if statements, but what about loops? The same rules apply, with special handling of the iteration constructs. For for loops, while loops, and do-while loops, if the loop conditional is unknown, the body of the loop is evaluated exactly once as an ambiguous block. If the iteration condition is known for the first few iterations, but later becomes unknown, then the block is evaluated one more time in ambiguous mode as a sort of “clean up.” Note that a for loop conditional is the middle argument, i.e. the “i < Date.now()" bit below:

for (var i = 0, i < Date.now(); i++) {}

For-in loops are different than the other loops, since they don't have an iteration condition. Instead, a for-in loop is evaluated in ambiguous mode if the value to be iterated over is unknown, as shown below:

for (var i in Date.now()) {}

There is one more important case that the code processor handles: what happens when a function is called inside of an ambiguous block? That will be discussed in my next post dealing with ambiguous contexts, so stay tuned.

Version 0.3.1 of the Titanium Code Processor has been released!

New Features

• Added support for parsing values from Ti.UI.createXXX constructors
• Added support for Ti.UI.Window.url

These new features are all under the hood improvements that increase the intelligence of the code processor and make the results more accurate.

Bug Fixes

• Fixed a bug where deferred analysis of functions wasn’t setting up the proper context
• Prevented duplicate errors and warnings from being reported

The first bug occurred when evaluation of a function was deferred. Functions are deferred either because they are a callback (addEventListener/setTimeout/etc) or because they weren’t analyzed and the processUnvisitedCode option was set to true. When a deferred function was evaluated, the context stack wasn’t being set up properly, and all of the closure variables (variables defined outside the function itself) were missing.

The second bug was really just an aesthetic thing that came about as a side effect of the code processors’ error recovery mechanisms. In a normal JavaScript engine, execution stops completely when an exception occurs and the error is only reported once (by definition). In the code processor with exception recovery enabled, the same “bad” line of code could be visited multiple times, thus throwing the exception multiple times. I now take all of these exceptions and roll them into a single exception with a count message.

This post has been a long time coming, sorry for the delay (work has been really busy lately)! In a previous post I discussed the basic concepts behind how I do dynamic offline analysis of JavaScript in the Titanium Code Processor. Today I want to follow up on this post and talk a little more about unknown values.

An unknown value is its own data type. Technically, it has no type and represents all types at the same time. An unknown value is generated whenever it is not possible to evaluate an expression. There are many ways that these values can be generated, but we’ll start with a simple example:

var d = Date.now();

Obviously we don’t know what the time will be when the app is run, so the code processor simply returns unknown in this instance. Date is significant because it is the only part of the ECMAScript spec that generates an unknown value from all known values. There are other ways to generate unknown values though; most references to the Titanium API generate unknown values for instance. Once we have our unknown value, the next question is then “how does this affect everything else?”

The rules are really quite simple: any expression involving an unknown value produces an unknown value. For example, all of these expressions produce unknown values:

var d = Date.now();
d++;
d + 10;
d * 10;
/[a-z]/.test(d);
typeof d;
!!d;

The last two are significant in that the expected behavior does not apply. typeof is supposed to always return a string, but in this case it returns the value unknown. Similarly, !!d is often used to cast a value to a boolean, but in this case it also returns the value unknown.

This behavior makes unknown values “viral” in the sense that once something becomes unknown, it tends to make everything it touches unknown as well. This can have especially profound effects on conditionals, which I’ll talk about in my next post.

Version 0.3.0 of the Titanium Code Processor has been released! The big new feature that warranted the minor version bump is a re-worked CLI with lots of new features

New Features

• Reworked the CLI interface to be much more robust
  • The code processor now takes a sub-command, one of ‘options’, ‘plugins’, ‘analyze’, and ‘subprocess’
  • The ‘subprocess’ sub-command provides an interactive, structured mechanism for calling the code processor from other programs
• Plugins can now take options
  • Options must be specified using a configuration file
• Plugins can now reside anywhere
  • To specify plugins in another location, they must be specified in a configuration file
• The ti-api-processor plugin now allows you to specify values for any primitive type in the API
  • This can be used to see how an app will react to, say, a specific screen size
• Plugins are now checked to make sure their dependencies are also loaded
• Added –all-plugins and –non-ti-plugins flags to the CLI to load all plugins or all non-Titanium-specific plugins, respectively
  • Now, if no plugins are specified, no plugins are loaded

Bug Fixes

• Fixed a bug where the code processor crashes when encountering a reference to an undeclared variable that is named the same as an Object prototype property
• Added a lot of configuration validation to prevent unexpected behavior/crashes when supplied with bad configuration data

The primary impetus with these new features was to add a new interface for studio to interact with. As part of this process, probably the biggest thing I added was support for reading options from a config file. This config file, detailed in the project README, allows for greater control over options than is possible from the command line. Another advantage to using a config file is that the “titanium” CLI command is no longer used, which shaves about 2 seconds off the startup time and allows people without the Titanium CLI installed to use the code processor.