Untitled Coding Blog

This is the final part of the series about the C# code analyzer and interpreter that I created a while back. The actual execution and interpretation of the C# code are explained in this post. It is the last post in this series. To begin with, in very simple terms each word in the C# code can have an associated action that needs to be executed when the code is read by the analyzer in the proper order. For example, a word in the code might be a variable name. In this case, the reference corresponding to that variable is located and stored in a temporary buffer once the word is read. After that, it can be used from the buffer for another operation like invoking a method on the object/objects that the reference references. In case it has to call a method, it needs to locate the body of the method and jump to the method implementation and start reading it. With constructors, it is pretty much the same thing with the only difference being the fact that it always returns a single object and...

This is a continuation of my blog series about writing a hybrid C# code analyzer and interpreter. Compared to part one, I renamed the variable references from "TrackedVariableReference" to "EvaluatedObjectReference" and a variable is now known as an "EvalutedObject" or any subtypes derived from it. This part will focus on the simulation of the code execution. The core part is the object that stores the current execution state which is of type "CodeEvaluatorExecutionState". The most important things stored in this state object are the objects of the type "CodeEvaluatorExecutionFrame". These objects represent a method call and store all the local parameters corresponding to a method call. These parameters include the local "this" reference, the local objects created inside the method, the passed parameters from caller of the method and a special slot for a reference which contains the results of an expression. This last slot ...

The purpose of this C# analyzer is to see all possible execution paths from any entry point inside the code. Currently the entry point can be only a method. There are multiple ways to deal with this. The approach would be to rewrite all existing code and rewrite all conditional statement so that they are true all the time. This approach has numerous disadvantages. Firstly, it will actually execute the code and any calls to external resources such as databases will be executed. Since the code has been altered, there is also no guarantee that it won't produce exceptions at runtime. And for really big code bases, it will be incredibly slow and it will require actual compilation of the modified code which may take even more time. My approach is to write a C# interpreter with some special conditions that will go through all possible execution paths. In order to go through all the execution paths, our interpreter will need to ignore all the conditional statements and jump directly ...