Nullness Analysis in Boolean Form

Attempts to dereference nil result in anexception or a segmentation fault. Hence itis importantto know those program points where this might occur and provethe others (or the entire program) safe.Nullness analysis of computer programs checks or infers non-nil annotationsfor variables and object fields. Most nullnessanalyses currently use run-time checks or are incorrect or only verifymanual annotations. We use here abstract interpretationto build and prove correct a static nullness analysis for Javabytecode which infers non-nil annotations. It isbased on Boolean formulas, implemented with binary decisiondiagrams. Our experiments show it faster and more precise than the correctnullness analysis by Hubert, Jensen and Pichardie.We deal with static fields and exceptions, which isnot the case of most other analyses. We claim that the result istheoretically clean and the implementation strong and scalable

Automatic Repair of Buggy If Conditions and Missing Preconditions with SMT

We present Nopol, an approach for automatically repairing buggy if conditions and missing preconditions. As input, it takes a program and a test suite which contains passing test cases modeling the expected behavior of the program and at least one failing test case embodying the bug to be repaired. It consists of collecting data from multiple instrumented test suite executions, transforming this data into a Satisfiability Modulo Theory (SMT) problem, and translating the SMT result -- if there exists one -- into a source code patch. Nopol repairs object oriented code and allows the patches to contain nullness checks as well as specific method calls.Comment: CSTVA'2014, India (2014

Inferring Complete Initialization of Arrays

We define an automaton-based abstract interpretation of a trace semantics which identifies loops that definitely initialize all elements of an array to values satisfying a given property, a useful piece of information for the static analysis of Java-like languages. This results in a completely automatic and efficient analysis, that does not use manual code annotations. We give a formal proof of correctness that considers aspects such as side-effects of method calls. We show how the identification of those loops can be lifted to global invariants about the contents of elements of fields of array type, that hold everywhere in the code where those elements are accessed. This makes our work more significant and useful for the static analysis of real programs. The implementation of our analysis inside the Julia analyzer is both efficient and precise

STATIC TYPE CHECKER TOOLS FOR DART

This project presents the static type checkers that I developed for the optional type system of the Dart programming language. Dart is an optionally typed language and as a result has an unsound type system. In this project I have created the static type checker tools for dart. The first static type checker tool ensures mandatory typing of Dart code. This checker can be invoked by giving a new compiler option that I have added to the compiler configuration. This checker will help in catching any type errors early at compile time rather than at run time. The second static type checker improves the Dart’s support for covariant generics. This static checker issues warnings at compile time if the covariant use of generics is followed by a modification of the collection passed covariantly. I have also introduced three annotations that will add more type safety to the Dart programming language. The @notnull annotation is to ensure that null values are not passed as arguments to method parameters. This nullness checker ensures that a running program will never throw a null pointer exception. The @modifies annotation supports the covariance check. The @linear annotation is used to prevent unexpected modification of objects by aliasing. The @linear annotation can be used in conjunction with Dart isolates for concurrent programming

A Non-Null Annotation Inferencer for Java Bytecode

We present a non-null annotations inferencer for the Java bytecode language. We previously proposed an analysis to infer non-null annotations and proved it soundness and completeness with respect to a state of the art type system. This paper proposes extensions to our former analysis in order to deal with the Java bytecode language. We have implemented both analyses and compared their behaviour on several benchmarks. The results show a substantial improvement in the precision and, despite being a whole-program analysis, production applications can be analyzed within minutes

A Java typestate checker supporting inheritance

This work was partially supported by the EU H2020 RISE programme under the Marie Skłodowska-Curie grant agreement No. 778233 (BehAPI) and by NOVA LINCS UIDB/04516/2020/TRA/BIM/07 ) via the Portuguese Fundação para a Ciência e a Tecnologia. Publisher Copyright: © 2022 Elsevier B.V.Detecting programming errors in software is increasingly important, and building tools that help developers with this task is a crucial area of investigation on which the industry depends. Leveraging on the observation that in Object-Oriented Programming (OOP) it is natural to define stateful objects where the safe use of methods depends on their internal state, we present Java Typestate Checker (JATYC), a tool that verifies Java source code with respect to typestates. A typestate defines the object's states, the methods that can be called in each state, and the states resulting from the calls. The tool statically verifies that when a Java program runs: sequences of method calls obey to object's protocols; objects' protocols are completed; null-pointer exceptions are not raised; subclasses' instances respect the protocol of their superclasses. To the best of our knowledge, this is the first OOP tool that simultaneously tackles all these aspects.publishersversionpublishe

Scala with Explicit Nulls

The Scala programming language makes all reference types implicitly nullable. This is a problem, because null references do not support most operations that do make sense on regular objects, leading to runtime errors. In this paper, we present a modification to the Scala type system that makes nullability explicit in the types. Specifically, we make reference types non-nullable by default, while still allowing for nullable types via union types. We have implemented this design for explicit nulls as a fork of the Dotty (Scala 3) compiler. We evaluate our scheme by migrating a number of Scala libraries to use explicit nulls. Finally, we give a denotational semantics of type nullification, the interoperability layer between Java and Scala with explicit nulls. We show a soundness theorem stating that, for variants of System F_? that model Java and Scala, nullification preserves values of types

Nopol: Automatic Repair of Conditional Statement Bugs in Java Programs

International audienceWe propose NOPOL, an approach to automatic repair of buggy conditional statements (i.e., if-then-else statements). This approach takes a buggy program as well as a test suite as input and generates a patch with a conditional expression as output. The test suite is required to contain passing test cases to model the expected behavior of the program and at least one failing test case that reveals the bug to be repaired. The process of NOPOL consists of three major phases. First, NOPOL employs angelic fix localization to identify expected values of a condition during the test execution. Second, runtime trace collection is used to collect variables and their actual values, including primitive data types and objected-oriented features (e.g., nullness checks), to serve as building blocks for patch generation. Third, NOPOL encodes these collected data into an instance of a Satisfiability Modulo Theory (SMT) problem; then a feasible solution to the SMT instance is translated back into a code patch. We evaluate NOPOL on 22 real-world bugs (16 bugs with buggy IF conditions and 6 bugs with missing preconditions) on two large open-source projects, namely Apache Commons Math and Apache Commons Lang. Empirical analysis on these bugs shows that our approach can effectively fix bugs with buggy IF conditions and missing preconditions. We illustrate the capabilities and limitations of NOPOL using case studies of real bug fixes

Analyzing program analyses

We want to prove that a static analysis of a given program is complete, namely, no imprecision arises when asking some query on the program behavior in the concrete (i.e., for its concrete semantics) or in the abstract (i.e., for its abstract interpretation). Completeness proofs are therefore useful to assign confidence to alarms raised by static analyses. We introduce the completeness class of an abstraction as the set of all programs for which the abstraction is complete. Our first result shows that for any nontrivial abstraction, its completeness class is not recursively enumerable. We then introduce a stratified deductive system a2A to prove the completeness of program analyses over an abstract domain A. We prove the soundness of the deductive system. We observe that the only sources of incompleteness are assignments and Boolean tests \u2014 unlikely a common belief in static analysis, joins do not induce incompleteness. The first layer of this proof system is generic, abstraction-agnostic, and it deals with the standard constructs for program composition, that is, sequential composition, branching and guarded iteration. The second layer is instead abstraction-specific: the designer of an abstract domain A provides conditions for completeness in A of assignments and Boolean tests which have to be checked by a suitable static analysis or assumed in the completeness proof as hypotheses. We instantiate the second layer of this proof system first with a generic nonrelational abstraction in order to provide a sound rule for the completeness of assignments. Orthogonally, we instantiate it to the numerical abstract domains of Intervals and Octagons, providing necessary and sufficient conditions for the completeness of their Boolean tests and of assignments for Octagons