Automatic generation of library bindings using static analysis

Ravitch, Tristan; Jackson, Steve; Aderhold, Eric; Liblit, Ben

doi:10.1145/1543135.1542516

Cited by 5 publications

(2 citation statements)

References 10 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Another approach generates language bindings for annotated C and C++ header files [5,14]. Ravitch et al reduce the annotations required for generating idiomatic bindings [22]. Jinn is more practical than these approaches, because it does not require developers to rewrite or annotate their code in a different language.…”

Section: Language Approaches To Ffi Safetymentioning

confidence: 99%

See 1 more Smart Citation

Jinn

et al. 2010

View full text Add to dashboard Cite

Programming language specifications mandate static and dynamic analyses to preclude syntactic and semantic errors. Although individual languages are usually well-specified, composing languages is not, and this poor specification is a source of many errors in multilingual programs. For example, virtually all Java programs compose Java and C using the Java Native Interface (JNI). Since JNI is informally specified, developers have difficulty using it correctly, and current Java compilers and virtual machines (VMs) inconsistently check only a subset of JNI constraints. This paper's most significant contribution is to show how to synthesize dynamic analyses from state machines to detect foreign function interface (FFI) violations. We identify three classes of FFI constraints encoded by eleven state machines that capture thousands of JNI and Python/C FFI rules. We use a mapping function to specify which state machines, transitions, and program entities (threads, objects, references) to check at each FFI call and return. From this function, we synthesize a context-specific dynamic analysis to find FFI bugs. We build bug detection tools for JNI and Python/C using this approach. For JNI, we dynamically and transparently interpose the analysis on Java and C language transitions through the JVM tools interface. The resulting tool, called Jinn, is compiler and virtual machine independent. It detects and diagnoses a wide variety of FFI bugs that other tools miss. This approach greatly reduces the annotation burden by exploiting common FFI constraints: whereas the generated Jinn code is 22,000+ lines, we wrote only 1,400 lines of state machine and mapping code. Overall, this paper lays the foundation for a more principled approach to developing correct multilingual software and a more concise and automated approach to FFI specification.

show abstract

Section: Language Approaches To Ffi Safetymentioning

confidence: 99%

“…Such multilingual programs require additional specification due to syntactic and semantic language differences. Well-designed and well-specified foreign function interfaces (FFIs) include recent integrated language designs [13,25] and language binding synthesizers [5,22], but programmers have not yet widely adopted them.…”

Section: Introductionmentioning

confidence: 99%

Jinn

et al. 2010

View full text Add to dashboard Cite

show abstract

Exposing Behavioral Differences in Cross-Language API Mapping Relations

Zhong

Thummalapenta

Xie

2013

Lecture Notes in Computer Science

View full text Add to dashboard Cite

Abstract. Due to various considerations, software vendors often translate their applications from one programming language to another, either manually or with the support of translation tools. Both these scenarios require translation of many call sites of API elements (i.e., classes, methods, and fields of API libraries). API mapping relations, either acquired by experienced programmers or already incorporated in translation tools, are much valuable in the translation process, since they describe mapping relations between source API elements and their equivalent target API elements. However, in an API mapping relation, a source API element and its target API elements may have behavioral differences, and such differences could lead to defects in the translated code. So far, to the best of our knowledge, there exists no previous study for exposing or understanding such differences. In this paper, we make the first attempt to expose and analyze behavioral differences in cross-language API mapping relations. From our result, we summarize eight findings and their implications that can improve effectiveness of translation tools, and also assist programmers in understanding the differences between mapped API elements of different languages during the translation process. Some exposed behavioral differences can indicate defects in translation tools, and four such new defects were confirmed by the developers of those tools.

show abstract