Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

js_wala #5

Open
mingshanjianke opened this issue Jan 17, 2016 · 3 comments
Open

js_wala #5

mingshanjianke opened this issue Jan 17, 2016 · 3 comments

Comments

@mingshanjianke
Copy link

hi,
I have some confusion about the JS_WALA. Firstly, I am confused why we should normalize the js first? Is it just for adapting the lots of cases in js of html? Secondly, I am confused why the generated CFG have a ring ? Finally, I think when put some js into "normalizer", the "normalizer" make many temporary variables. When I want to analyze the define and use of js , it is too difficulty. Could you give me some advice for it?Thanks!

@xiemaisi
Copy link

Firstly, I am confused why we should normalize the js first? Is it just for adapting the lots of cases in js of html?

Yes. The normalisation flattens nested expressions, and replaces complex language constructs by simpler ones where possible (e.g., x -= y is expressed as x = x - y). This is useful for many analyses, since you have to consider fewer constructs.

Secondly, I am confused why the generated CFG have a ring?

I am confused by this question. What do you mean by a "ring"?

the "normalizer" make many temporary variables.

Yes. This is because complex nested expressions are replaced by a series of simpler statements that compute the same value. Basically, the new temporary variables give names to results of nested sub-expressions.

@mingshanjianke
Copy link
Author

What I mean the "ring" is that the last statement is point to the first statement,like this "ExpressionStatement at 2 b=a --> [Program at 1]".

@xiemaisi
Copy link

Ah, I see what you mean (though I still don't understand why you refer to it as a "ring"; your example is not cyclic).

The CFGs we construct are intraprocedural, that is, there is one CFG for each function, and one for each toplevel script. In general, it's useful for CFGs to have a single entry node and a single exit node, so we create an artificial Entry node for each script and function. Similarly, we could have created corresponding Exit nodes, but instead we decided to overload the Program node of a script (and, similarly, the FunctionExpression and FunctionDeclaration nodes of a function) to serve as exit node.

For instance, in the example, the CFG of the toplevel script has Entry at 1:0 as its entry node, and Program at 1:0 as its exit node.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants