New Error-recovery Techniques for Faulty-Calls of Functions

In this paper, we introduce type systems to detect faulty calls of functions in a program. The intended meaning of the faulty call is calling a function with a miss-match to the number of its arguments. We use error-detecting semantics that when detects the faulty calls, doesn't proceed to the next state. Type systems are used in the process of analysis and in repairing. The paper presents two type systems: the safety type system which checks the safety of a given program and the repairing type system which corrects errors. The repairing process is made by replacing the faulty call of function with a correct one. In the repairing process simple interactive input/output statements are used. The interaction (input/output) helps to get the lost parameters by interacting with the user; informing him about the number of lost parameters. The user can then input these parameters.


Introduction
Programmers use functions in many cases as they make their work easier to follow.In most of programming languages, a function's definition consists of function's name, list of parameters and function's body.This is the basic structure of functions.Often the function's name with the list of parameters is called a declaration.The parameters are taken from the user to operate on by the function's body.The function's body is a group of statements that will be executed when the function is called.The value of the parameter is passed to the function during the call.When the programmer calls a function and passes to it a wrong number of parameters, an error occurs (El-Zawawy, 2012;El-Zawawy & Nayel, 2011).This paper presents a semantic approach to repair this kind of problems, such that if a function is called with passing a wrong number of parameters, the semantics gets stuck and does not proceeds to the next state.This semantics is called error-detecting semantics.The analysis is made via type system as it easier to work with.It is also easy to be related to a mathematical proof.We introduced two type systems; the first is to check the safety of the program (safety type system) and the second is to repair the errors (repair type system) (El-Zawawy, 2011c;El-Zawawy, 2011a;El-Zawawy, 2012;El-Zawawy & Nayel, 2011;El-Zawawy, 2011b).
Example: succ(x) {x=x+1;} The function succ calculates the successor of an integer x.To find the successor of 5 we need to run succ(5).But if we run succ( ) or succ (5,6), we get error messages.These two calls are called faulty calls.To solve this problem, we use the interaction between the program and the environment to get the missing parameter.If a faulty call exists, the safety type system detects it and doesn't continue to the next state.The repair type system repairs this error.The error is repaired by using a function put to inform the user about the right number of parameters needed.We use get to get the new values of the parameters.The new values will be assigned to fresh variables to save the new parameters values.After getting all the parameters, we call the function again with these new values.Note that: We ignore any values passed to the function in the first call "the faulty one" (El-Zawawy, 2011c;El-Zawawy, 2011a).We use type systems in the analysis as they provide useful features like optimization and documentation.
The rest of the paper is organized as follows.Section 2 introduces the syntax of the language and the error detecting semantics with the safety type system.In Section 3 the repair type system is presented with the proof of its soundness.Section 4 concludes the paper and Section 5 reviews some related work.

Error Detection
This section presents a small model for faulty function call (with respect to the number of arguments).When a function is called, it must be passed to the write number of parameters, according to its definition.The syntax of the While language appears in Figure 1.It is extended with statements for function call and interaction (getting or putting a value).The goal in this section is to capture the error when a faulty call is attempted (El-Zawawy, 2012;El-Zawawy & Nayel, 2011).In Figure 1, the set of statements Stm, and the set of the atomic statements Atm, are defined over the set of function names F. Var denotes the set of variables.a ranges over Atm, S over Stm, x over Var, and n over .We treat the Boolean values true and false as the numeric values 1 and 0. The semantics state can be defined as a pair ( , ) such that, 1-The store is the function that maps the set of variables Var to the integers , .2-The status function is a map from the set of function names F to {a(n), na}, where a(n) means that the function takes n arguments and na denotes taking no arguments.The rules of this transition system are presented in Figure 2.These rules allow no reach for a final state in case of faulty calls.So they get stuck when they found any faulty calls to the function.The Rules and define a function f whose body is {S}.As we can see the function status is updated with a(n) or na according to the function definition.In the function is defined to take n parameter, so the status of f is a(n).But in the function is defined to take no parameter so f has the status na.The rules and treat function calls.But we have a condition that the function status must agree with the function being called so the rule could be applied.If that condition is not satisfied as in and , the execution gets stocked.The rule updates the store with the new value of x.The rules do not affect the store or the state.In the rule , only gets a numeric value so it doesn't affect the state.The rule for sequence, has the familiar look that we know and it aborts if either of its statements get stuck in or .Also in and every time we evaluate the guard expression, we execute either S t or S f according to the value of a.The rules of if statement get stuck in if S t or S f get stuck in , respectively.The rule evaluates S t and the while statement if a evaluates to 1.The rule deals with the case when (a) evaluates to zero, meaning that the condition is not satisfied.The while statement gets stuck in if S t gets stuck as in or if the while statement gets stuck as in .
To check the safety of a program, a type system is used.This type system is defined in Figure 3 and is called Safety type system.The analysis here is a forward analysis and the types are the maps : , , where a(n) stands for taking n arguments and na for taking no arguments.The type decides for every function whether it takes n parameters or none.In Figure 3, the type judgment takes the form : . So if the type was c before executing S then it will be c' after the execution.
The rules and deal with the function definition. is for a function named f that takes n parameters.After executing this statement, the type map f to a(n) otherwise act like c.As for , it acts just the same but with mapping f to na meaning that f takes no parameters at all.The rule have a condition that the function f must have the type a(m) so we can detect any errors when passing the wrong number of parameter.It deals with both cases, less or more parameter than we need.But  The remaining rules are straightforward to check.Now we can say that the type system is sound so there are no type errors according to: Suppose that in the safety-type system.Then if , then it is impossible to get , |.

Proof:
By structural induction on type derivation as follows: 1.For the rule , we assume

Repairing Faulty Calls
Now, after we have checked the safety of the program, we may proceed to the repairing process.We are interested in only the errors that result from faulty calls.We have two kinds of functions; one that takes no arguments; and the other takes n arguments.The easy part is when we deal with the one that takes no argument.In this case, if by mistake any argument is passed to the function, we can easily ignore these values.The tricky part occurs when we deal with a function that takes parameters.We have two cases to deal with; the first case is when the number of parameters passed is less than the number in the function definition.The second case is when this number is more than the function needed.In both cases, we ignore all the values passed to the function in the faulty call.Then, we use put to output the right number of parameters needed, and then use to get a new values for the parameters from the user.For example, if we define a function named r by: ; 10 10 ; To call this function in the right way, we have to run .But running for example 6 is wrong.This can be repaired by ignoring the value passed here which is 6.So, 6 can be replaced by i.e. 6 .; ;

, ;
In line 1, 2 informs the user that we need only two parameters to the function.In line 2, the user enters the new values and they are stored in and , respectively.In line 3, the function call is made with the new values and the right number of parameters.For the repair type system, the types are the same as that of the safety type system.But the form of the type judgment will have a transformation component.The judgment will take the form : . This means that S can be replaced by S'.The rules of this type system appear in Figure 4.This type system is called the Repair type system as it replaces the wrong statement whenever it is possible.In Figure 4, the rule makes the replacement if the number of parameters is not the same as the one that the function takes.The type system detects it, since it is a forward type system. .As induction hypothesis we may assume the required for the sub statements.So , , ), then , , .The remaining rules are straightforward to check.

Conclusion
This paper presents a type system for detecting faulty calls of functions and a type system for repairing these errors by interacting with the user through input/output statements.The errors that we treat are the function calls that have wrong number of arguments (more or less) than the function needs.To repair these errors, we ignore all the parameter values and ask the user to re-input them and when we get these values we call the function again with them.The soundness of both type systems is proved via induction on the type rules.

Related and Future Work
In (Fischer, Saabas, & Uustalu, 2009) two problems related to file access errors and queues are approached.The file problem happens when opening a file that is already opened or closing a file that is already closed.Also reading from a closed file is another source of abortion.The work in (Fischer, Saabas, & Uustalu, 2009) ignores end of file errors for simplicity.For the concept of queue, this paper treats situations of adding values to full queues (over/under flow).
Type systems are used intensively (El-Zawawy, 2011c;El-Zawawy, 2011a;El-Zawawy, 2012;El-Zawawy & Nayel, 2011;El-Zawawy, 2011b) in program analysis.In (El-Zawawy, 2011c), the problem of dead-code elimination was approached with type systems.This optimization is based on flow-sensitive pointer analysis.The final type system is an enrichment of that pointer analysis.The work in (El-Zawawy, 2011c) deals with the memory safety of multi-threaded programs.This paper presents a type system for pointer analysis of multi-threaded programs.The memory-safety type system is a flow sensitive which invokes anther flow insensitive type system (for pointer analysis).Basic constructs treated by these flow-insensitive type systems (for pointer analysis) are parallel programming constructs.In Benton's work (Benton, 2004), static analysis is presented via elementary logic; type systems are used in the analysis to generalize it with Hoare logic which is used in the optimization of while programs.A data-structure repair-system is presented in (Demsky & Rinard, 2006).This system generates a repair algorithm for the input data structures that have the form of relational model.This algorithm detects and repairs the errors during the program execution.In (Denney & Fischer, 2003), the static safety of the program is proved to guarantee a dynamic safety.This is done using Hoare reference rules to check the safety policies.In this work, the soundness and completeness of safety policies on memory access and memory read and write are proved.The assertion violation is treated in (Elkarablieh, Garcia, Suen, & Khurshid, 2007) with a repairing algorithm that finds the errors and repairs them without terminating the program.This algorithm repairs complex structures with the ability to recover from future errors.
In (Frade, Saabas, & Uustalu, 2007) live variables analysis is treated as a classical data flow analysis, and shown to be certified on a variety of levels; completely analogous to certification of program safety or functional correctness.This paper shows that the type systems should be seen as foundational Hoare logic to study the same abstract semantics.The programs studied in (Frade, Saabas, & Uustalu, 2007) contain a provision for error-detection and error-recovery presented in (Horning, Lauer, Melliar-Smith, & Randell, 1974).The work in (Knoop, Rüthing, & Stefen, 1994) presents a version of the algorithm of lazy code motion that works on a flow graph.The algorithm is a life time optimal with a unidirectional analysis.
The work (Paleri, Srikant, & Shankar, 2003) presents a simple for partial redundancy elimination which is built up on the two concepts of partial availability and safe partial anticipability.This algorithm works on flow graph with four unidirectional analyses.This algorithm also integrates the notations of safety from the definition of partial availability and from the definition of safe partial anticipability.A program optimization approach is presented in (Saabas & Uustalu, 2008a).This work presents compositional type systems with a transformation component.Dead-code elimination and common sub-expression elimination are studied in (Saabas & Uustalu, 2008a).
The work in (Saabas & Uustalu, 2007) presents a type system for optimizing stack-based code.In this work, dead store instructions and load-pop pairs are treated with no need for assumption about input code.An algorithm for soundness proofs and strongest analysis is presented in a simple way in (Saabas & Uustalu, 2007).Optimizations of partial redundancy elimination are studied in (Saabas & Uustalu, 2008b).More precisely (Saabas & Uustalu, 2008b) optimizes the Hoare logic proofs of the given program with the help of a type derivation representation of the result of the underlying data flow analyses.
Mathematical domains and maps between domains can be used to mathematically represent programs and data structures.This representation is called denotation semantics of programs (Cazorla, Cuartero, Ruiz, & Pelayo, 2000;Guo, 2001;Schwartz, 1979).One of our directions for future research is to translate concepts of function repair to the side of denotation semantics (El-Zawawy & Jung, 2006;El-Zawawy, 2007).Doing so provides a good tool to mathematically study in deep function repair.Then obtained results can be translated back to the side of programs and data structures.

Figure 1 .
Figure 1.The programming language

Figure 2 .
Figure 2. Error detecting semantics as we can see the call statement doesn't change the type, and the same is true for .
The required results from the induction hypothesis on .The remaining rules are straightforward to check.