C to O-O Translation: Beyond the Easy Stuff
Marco Trudel∗, Carlo A. Furia∗, Martin Nordio∗, Bertrand Meyer∗ and Manuel Oriol† ∗ Chair of Software Engineering, ETH Zurich, Switzerland Email: fi[email protected] † Dept. of Computer Science, University of York, York, UK; [email protected] ABB Corporate Research, Industrial Software Systems, Baden-Dattwil,¨ Switzerland; [email protected]
Abstract—Can we reuse some of the huge code-base developed type system, and a sophisticated runtime that is not directly in C to take advantage of modern programming language accessible. There have been previous attempts to translate C features such as type safety, object-orientation, and contracts? into an object-oriented language (see the review in Section V). This paper presents a source-to-source translation of C code into Eiffel, a modern object-oriented programming language, and the A limitation of the resulting tools is that they hardly handle the supporting tool C2Eif. The translation is completely automatic trickier or specialized parts of the C language [4], which it is and supports the entire C language (ANSI, as well as many tempting to dismiss as unimportant “corner cases”, but figure GNU C Compiler extensions, through CIL) as used in practice, prominently in real-world programs; examples include calls to including its usage of native system libraries and inlined assembly pre-compiled C libraries (e.g., for I/O), inlined assembly, and code. Our experiments show that C2Eif can handle C applications setjmp longjmp and libraries of significant size (such as vim and libgsl), as well unrestricted branch instructions including and . as challenging benchmarks such as the GCC torture tests. The One of the distinctive features of the present work is that it produced Eiffel code is functionally equivalent to the original C does not stop at the core features but extends over the often code, and takes advantage of some of Eiffel’s features to produce difficult “last mile”: it covers the entire C language as used in safe and easy-to-debug translations. practice. The completeness of the translation scheme is attested by the set of example programs to which the translation was I.INTRODUCTION successfully applied, as described in Section IV, including Programming languages have significantly evolved since the major utilities such as the vim editor (276 KLOC), major original design of C in the 1970’s as a “system implemen- libraries such as libgsl (238 KLOC), and the challenging tation language” [1] for the Unix operating system. C was GCC “torture” tests for C compilers. a high-level language by the standards of the time, but it is C2Eif is open source and available for download1: pronouncedly low-level compared with modern programming http://se.inf.ethz.ch/research/c2eif paradigms, as it lacks advanced features—static type safety, Sections II–III describe the distinctive features of the encapsulation, inheritance, and contracts [2], to mention just translation: it supports the complete C language (including a few—that can have a major impact on programmer’s pro- pointer arithmetic, unrestricted branch instructions, and ductivity and on software quality and maintainability. function pointers) with its native system libraries; it complies C still fares as the most popular general-purpose program- with ANSI C as well as many GNU C Compiler extensions ming language [3], and countless C applications are still being through the CIL framework [5]; it is fully automatic, and actively written and maintained, that take advantage of the it handles complete applications and libraries of significant language’s conciseness, speed, ubiquitous support, and huge size; the generated Eiffel code is functionally equivalent to code-base. An automated solution to translate and integrate the original C code (as demonstrated by running thorough C code into a modern language would combine the large test suites), and takes advantage of some advanced features availability of C programs in disparate domains with the (such as classes and contracts) to facilitate debugging of integration in a modern language that facilitates writing safe, programming mistakes. robust, and easy-to-maintain applications. In our experiments, C2Eif translated completely The present paper describes the fully automatic translation automatically over 900,000 lines of C code from of C applications into Eiffel, an object-oriented programming real-world applications, libraries, and testsuites, language, and its implementation C2Eif. While the most producing functionally equivalent2 Eiffel code. common approaches to re-use C code in other host languages are based on “foreign function APIs” (see Section V for exam- Safer code. Translating C code to Eiffel with C2Eif is quite ples), source-to-source translation solves a different problem, useful to reuse C applications in a modern environment, but and has some distinctive benefits: the translated code can take it also implies several valuable side-benefits—demonstrated in full advantage of the high-level nature of the target language Section IV. First, the translated code blends well with hand- and of its safer runtime. written Eiffel code because it is not a mere transliteration Translating C to a high-level Main features of C2Eif. 1The webpage includes C2Eif’s sources, pre-compiled binaries, source and object-oriented language is challenging because it requires binaries of all translated programs in Table I, and a user guide. adapting to a more abstract memory representation, a tighter 2As per standard regression testsuites and general usage. from C; it is thus modifiable with Eiffel’s native tools and set of C statements, without having to deal with each of environments (EiffelStudio and related analysis and verifica- them explicitly. C2Eif then translates CIL programs to Eiffel tion tools). Second, the translation automatically introduces projects consisting of collections of classes that rely on a small simple contracts, which help detect recurring mistakes such set of Eiffel helper classes (described below). Such projects as out-of-bound array access or null-pointer dereferencing. can be compiled with any standard Eiffel compiler. To demonstrate this, Section IV-C discusses how we easily Incremental translation. C2Eif implements a translation discovered a few unknown bugs in widely used C programs T from CIL C to Eiffel as a series T1,...,Tn of successive (such as libgmp) just by translating them into Eiffel and incremental transformations on the Abstract Syntax Tree. running standard tests. While the purpose of C2Eif is not Every transformation Ti targets exactly one language aspect to debug C programs, the source of errors is usually more (for example, loops or inlined assembly code) and produces a evident when executing applications translated in Eiffel— program in an intermediate language Li which is a mixture of either because a contract violation occurs, or because the C and Eiffel constructs: the code progressively morphs from Eiffel program fails sooner, before the effects of the error C to Eiffel code. The current implementation uses around 40 propagate to unrelated portions of the code. The translated such transformations (i.e., n = 40). Combining several sim- C code also benefits from the tighter Eiffel runtime, so that ple transformations improves the decoupling among different certain buffer overflow errors are harder to exploit than in language constructs and facilitates reuse (e.g., to implement native C environments. Thus, Eiffel code generated by C2Eif a translator of C to Java) and debugging: the intermediate is often safer and easy to maintain and debug. programs are easily understandable by programmers familiar Why Eiffel? We chose Eiffel as the target language not only with both C and Eiffel. out of our familiarity with it, but also because it offers features Helper classes. The core of the translation from C to Eiffel that complement C’s, such as an emphasis on correctness [6] must ensure that Eiffel applications have access to objects through the native support of contracts. In addition, Eiffel with the same capabilities as those of their counterparts in uncompromisingly epitomizes the object-oriented paradigm, C; for example, an Eiffel class that translates a C struct hence translating C into it cannot take the shortcut of merely has to support field access and every other operation defined transliterating similar constructs (as it would have been pos- on structs. Conversely, C external pre-compiled code may sible, for example, with C++). The results of the paper are also have to access the Eiffel representations of C constructs; thus likely applicable with little effort to other object-oriented for example, the Eiffel translation of a C program calling languages such as Java and C#; we plan to pursue this direction printf to print a local string variable str of type char∗ must in future work. grant printf access to the Eiffel object that translates str, in An extended version of this paper, including a few more conformance with C’s conventions on strings. To meet these examples and details, is available as technical report [7]. A requirements, C2Eif includes a limited number of hand-written companion paper presents the tool C2Eif from the user’s point helper Eiffel classes that bridge the Eiffel and C environments; of view [8]. their names are prefixed by CE for C and Eiffel. Rather than directly replicating or wrapping commonly used external II.OVERVIEW AND ARCHITECTURE libraries (such as stdio and stdlib), the helper classes C2Eif is a compiler with graphical user interface that translates target C fundamental language features and in particular types C programs to Eiffel programs. The translation is a complete and type constructors. This approach works with any external Eiffel application that replicates the functionalities of the C library, even non-standard ones, and is easier to maintain source application. C2Eif is implemented in Eiffel. because it involves only a limited number of classes. We now give a concise description of the most important helper classes;
Helper Section III shows detailed examples of their usage. Classes • CE POINTER [G] represents C pointers of any type
Eiffel through the generic parameter G. It includes features to C application Eiffel CIL CIL C file application or Binary or library C2Eif Compiler library perform full-fledged pointer arithmetic and to get pointer representations that C can access but the Eiffel’s runtime will not modify (in particular, the garbage collector will Fig. 1. Overview of how C2Eif works. not modify pointed addresses nor relocate memory areas). • CE CLASS defines the basic interface of Eiffel classes High-level view. Figure 1 shows the overall picture of how translating unions and structs. It includes features (mem- C2Eif works. C2Eif inputs C projects (applications or libraries) bers) that return instances of class CE POINTER pointing processed with the C Intermediate Language (CIL) framework. to a memory representation of the structure that C can CIL [5] is a C front-end that simplifies programs written in access. ANSI C or using the GNU C Compiler extensions into a • CE ARRAY [G] extends CE POINTER and provides con- restricted subset of C amenable to program transformations; sistent array access to both C and Eiffel (according to for example, there is only one form of loop in CIL. Using their respective conventions). It includes contracts that CIL input to C2Eif ensures complete support of the whole check for out-of-bound access. • CE ROUTINE represents function pointers. It supports tegers), REAL (floating point numbers) with the appropriate calls to Eiffel routines through agents—Eiffel’s con- bit-size as follows4: struct for function objects (closures or delegates in other C TYPE T EIFFEL CLASS TTY (T ) languages)—and calls to (and callbacks from) external C char INTEGER 8 short int INTEGER 16 functions through raw function pointers. int, long int INTEGER 32 INTEGER 64 • CE VA LIST supports variadic functions, using Eiffel long long int float REAL 32 class TUPLE (sequences of elements of heterogeneous double REAL 64 type) to store a variable number of arguments. It offers long double REAL 96 an Eiffel interface that extends the standard C’s (declared Unsigned variants follow the same size conventions as in stdarg.h), as well as output in a format accessible signed integers but for class NATURAL; for example by external C code. TTY(unsigned short int) is NATURAL 16. Pointers. Pointer types are translated to Eiffel using class III.TRANSLATING C TO EIFFEL CE POINTER[G] with the generic parameter G instantiated with the pointed type: This section presents the major details of the translation T (T ∗)= CE POINTER [T (T)] T from C to Eiffel implemented in C2Eif, and illustrates TY TY the general rules with a number of small examples. The with the convention that TTY(void) maps to Eiffel class presentation breaks down T into several components that ANY, ancestor to every other class (Object in Java). The target different language aspects (for example, TTD maps C definition works recursively for multiple indirections; for type declarations to Eiffel classes); these components mirror example, CE POINTER[CE POINTER[REAL 32]] stands for the incremental transformations Ti of C2Eif (mentioned in TTY(float ∗∗). Section II) but occasionally overlook inessential details for Function pointers. Function pointers are translated to Eiffel greater presentation clarity. using class CE ROUTINE:
External functions in Eiffel. Eiffel code translated from C TTY (T0 (∗)(T1, ...,Tn))= CE ROUTINE normally includes calls to external C pre-compiled functions, whose actual arguments correspond to objects in the Eiffel CE ROUTINE inherits from CE POINTER [ANY], hence it runtime. This feature relies on the external Eiffel language behaves as a generic pointer, but it specializes it with ref- construct: Eiffel routines can be declared as external and erences to agents that wrap the functions pointed to; Sec- directly execute C code embedded as Eiffel strings3 or call tion III-B describes this mechanism. functions declared in header files. For example, the following Arrays. Array types are translated to Eiffel using class Eiffel routine (method) sin twice returns twice the sine of its CE ARRAY[G] with the generic parameter G instantiated argument by calling the C library function sin (declared in with the array base type: TTY(T [n])= CE ARRAY[TTY(T)]. math.h): The size parameter n, if present, does not affect the dec- laration, but initializations of array variables use it (see sin twice (arg: REAL 32): REAL 32 external C inline use
v: TTY (T) assign set v −− declares ‘set v’ as the setter of v example, the finalizer of CE ARRAY frees the array memory set v (a v: TTY (T)) do v := a v ; update memory field (”v”) end area by calling free on the attribute c pointer. Class CE CLASS, of which S is a descendant, implements To replicate the usage of malloc and free, we offer wrapper update memory field using reflection, so that the underlying C routines that emulate the syntax and functionalities of their C representation is created and updated dynamically only when homonym functions, but operate on CE POINTER: they get needed during execution (for example, to pass a struct in- raw C pointers by external calls to C library functions, convert stance to a native C library), thus avoiding any data duplication them to CE POINTER, and record the dynamic information overhead whenever possible. about allocated memory size. The latter is used to check The translation of union types follows the same lines as that successive usages conform to the declared size (see that of structs, with the only difference that classes translating Section IV-C). Finally, the creation procedure make cast of unions generate the underlying C representation in any case the helper classes can convert a generic pointer returned by upon initialization, even if the union is not passed to the malloc to the proper pointed type, according to the following C runtime; calls to update memory field update all attributes translation scheme: of the class to reflect the correct memory value. We found C CODE TRANSLATED EIFFEL CODE T∗ p; p: CE POINTER[TTY (T)] this to be a reasonable compromise between performance and p = (T ∗)malloc(sizeof(T)); create p.make cast (malloc (σ(T))) complexity of memory management of union types where, free(p); free(p) unlike structs, fields share the same memory space. where σ is an encoding of the size information. Example 1. Consider a C struct car that contains an integer Variable usage. The translation of variable usage is straight- field plate num and a string field brand: forward: variable reads in expressions are replicated verbatim, typedef struct { unsigned int plate num; char∗ brand; } car; and C assignments (=) become Eiffel assignments (:=); the lat- CE ARRAY CE POINTER The translation TTD introduces a class CAR as follows: ter is, for , , and classes translating C s and s, syntactic sugar for calls to setter routines class CAR inherit CE CLASS feature struct union that achieve the desired effect. The only exceptions occur plate num: NATURAL 32 assign set plate num when implicit type conversions in C must become explicit brand: CE POINTER [INTEGER 8] assign set brand in Eiffel, which may spoil the readability of the translated
set plate num (a plate num: NATURAL 32) code but is necessary with strong typing. For example, the do plate num := a plate num; update memory field (”plate num”) end C assignment cr = ’s’—assigning character constant ’s’ to cr set brand (a brand: CE POINTER [INTEGER 8]) variable of type char—becomes the Eiffel assignment do brand := a brand; update memory field (”brand”) end cr := (’s’).code.to integer 8 that encodes ’s’ with the proper end representation. Variable address. Whenever the address &v of a C variable B. Variable Initialization and Usage v of type T is taken, v is translated as an array of unit size v C Initialization. Eiffel variable declarations : only allocate and type T: TDE(T v)= TDE(T v[1]), and every usage of v is memory for a reference to objects of class C, and initialize adapted accordingly: &v becomes just v, and occurrences of it to Void (null in Java). The only exceptions are, once v in expressions become ∗v. This little hack makes it possible again, numeric types: a declaration such as n: INTEGER 64 to have Eiffel assignments translate C assignment uniformly; reserves memory for a 64-bit integer and initializes it to zero. otherwise, usages of v should have different translations ac- Therefore, every C local variable declaration T v of a variable v cording to whether the information about v’s memory location of type T may also produce an initialization, consisting of calls is copied around (with &) or not. to creation procedures of the corresponding helper classes, as Dereferencing, pointer arithmetic. The helper class specified by the declaration mapping TDE: CE POINTER features a query item that translates deref- v : T (T ) (NT) erencing (∗) of C pointers. Pointer arithmetic is translated TY TDE(T v;)= v : TTY (T ); create v.make( n1, . . . , nm ) (AT) verbatim, because class CE POINTER overloads the arith- v : TTY (T ); create v.make (OT) metic operators to be aliases of proper underlying pointer where definition (NT) applies if T is a numeric type; (AT) manipulations, so that an expression such as p + 3 in Eiffel, applies if T is an array type S[n1],...,[nm]; and (OT) applies for references p of type CE POINTER, hides the explicit otherwise. The creation procedure make of CE ARRAY takes expression c pointer + 3∗element size. a sequence of integer values to allocate the right amount of Using function pointers. Class CE ROUTINE, which memory for each array dimension; for example int a[2][3] is translates C function pointers, is usable both in the Eiffel initialized by create a.make( 2,3 ). and in the C environment (see Figure 2). On the Eiffel Memory management. Helper classes are regular Eiffel side, its instances wrap Eiffel routines using agents—Eiffel’s classes, therefore the Eiffel garbage collector disposes in- mechanism for function objects. A private attribute routine stances when they are no longer referenced (for example, references objects of type ROUTINE [ANY, TUPLE], an Eiffel system class that corresponds to agents wrapping routines with from pc := 0 until pc = −1 loop any number of arguments and argument types stored in a tuple. inspect pc Thus, Eiffel code can use the agent mechanism to create when 0 then T(s0); upd(pc) T(s ); upd pc instances of class ROUTINE. For example, if foo denotes a when 1 then 1 ( ) TCF(hs0, s1, . . . , sni) = . . routine of the current class and fp has type CE ROUTINE, . n T(s ); upd pc when then n ( ) create fp.make agent (agent foo) makes fp’s attribute routine end point to foo. On the C side, when function pointers are end directly created from C pointers (e.g., references to external pc is initially zero; every iteration of the loop body executes C functions), CE ROUTINE behaves as a wrapper of raw C spc for the current value of pc, and then updates pc (upd(pc)) function pointers, and dynamically creates invocations to the to determine the next instruction to be executed: blocks ending pointed functions using the library libffi. with jumps modify pc directly, other blocks increment it by The Eiffel interface to CE ROUTINE will then translate one, and exit blocks set it to −1, which makes the overall loop calls to wrapped functions into either agent invocations or terminate. external calls with libffi according to how the class has This translation supports all control-flow breaking instruc- been instantiated. Assume, for example, that fp is an object of tions, and in particular continue, break, and return, which are class CE ROUTINE that wraps a procedure with one integer special cases of goto. TCF, however, improves the readability argument. If fp has been created with an Eiffel agent foo as in these special cases by directly using auxiliary Boolean flag above, calling fp.call ([42]) wraps the call foo (42) (edge 1 variables (with the same names as the instruction they replace) in Figure 2); if, instead, fp only maintains a raw C function that are tested in the translated exit conditions and achieve the pointer, the same instruction fp.call ([42]) creates a native C same effect with smaller changes to the code structure. For ex- call using libffi (edge 2 in Figure 2). ample, while (n > 0){ if (n == 3) break; n−−; } becomes:
2:libffi from until break or not n >0 loop if n = 3 then break := True end if not break then n := n − 1 end 1:agent Eiffel C end
3:libffi Functions. Function definitions and calls directly translate Fig. 2. Function pointers. to routine definitions and calls in Eiffel. Translations of variadic function definitions use the Eiffel TUPLE class: The services of class CR ROUTINE behave as an adapter TCF(T0 var (T1a1,...,Tnan,...)) = between the procedural and object-oriented representation of var (args: TUPLE[a1 : TTY (T1); ... ; an : TTY (Tn)]): TTY (T0) routines: the signatures of C functions must change when they Eiffel’s type system prescribes that every (n + m)-TUPLE are translated to Eiffel routines, because routines in object- with types [T1,...,Tn,Tn+1,...,Tn+m], m ≥ 0, conforms oriented languages include references to a target object as to any shorter n-TUPLE with [T1,...,Tn]. Therefore, calls to implicit first argument. Calls from external C code to Eiffel variadic functions can use longer tuples to accommodate the routines are therefore intercepted at runtime with libffi additional optional arguments: callbacks (edge 3 in Figure 2) and dynamically converted to TCF(var (e1, . . . , en, en+1, . . . , en+m)) = suitable agent invocations. var ([T(e1),..., T(en), T(en+1),..., T(en+m)]) We can access arguments in a TUPLE either with standard C. Control Flow Eiffel syntax, or using the helper class CE VA LIST. With standard syntax, args.ai refers to the required argument with This section discusses the translation TCF of instructions a , 1 ≤ i ≤ n args T (T ) item k directing the control flow. Sequential composition, condition- name i , whereas . TY k ( ) refers k a 1 ≤ k ≤ n als, and loops are quite similar in C and Eiffel, hence have a to the -th argument k, for any (required) or straightforward translation (see [7]). k > n (optional), where TTY(Tk) is ak’s type. Alternatively, CE VA LIST provides a uniform interface to both Eiffel and Jumps. Eiffel enforces structured programming, hence it C that accesses argument lists sequentially, replicating and lacks control-flow breaking instructions such as C’s goto, interoperable with stdarg’s: break, continue, return. The translation TCF eliminates them along the lines of the global version—using Harel’s termi- argp: CE VA LIST create argp.make (args, n+1) nology [9]—of the structured programming theorem. Every e1 := va list.TTY (Tn+1) item −− first optional argument an+1 C function foo using goto determines a list of instructions e2 := va list.TTY (Tn+2) item −− second optional argument an+2 ... s0, s1, . . . ,sn, where each si is a maximal sequential block of instructions without labels after the first instruction or jumps Long jumps. The C library setjmp provides the functions before the last one. TCF translates foo’s body into a single loop setjmp and longjmp to save an arbitrary return point and over an auxiliary integer variable pc that emulates a program jump back to it across function call boundaries. The wrapping counter: mechanism used for external functions (see Section III-D) does not work to replicate long jumps, because the return values GNU/Linux box (kernel 2.6.37) with a 2.66 GHz Intel dual- saved by setjmp wrapped as an external function are no longer core CPU and 8 GB of RAM, GCC 4.5.1, CIL 1.3.7, Eif- valid after execution leaves the wrapper. Therefore, C2Eif felStudio 7.0.8. For each application, library, and testsuite translates setjmp and longjmp by means of the helper class Table I reports: (1) the size (in lines of code) of the CIL CE EXCEPTION. As the name suggests, CE EXCEPTION version of the C code and of the translated Eiffel code; (2) the uses Eiffel’s exception propagation mechanism to go back in number of Eiffel classes created; (3) the time (in seconds) the call stack to the allocation frame of the function that called spent by C2Eif to perform the source-to-source translation (not setjmp. There, translated goto instructions jump to the specific including compilation from Eiffel source to binary); (4) the point saved with setjmp within the function body. size of the binaries (in MBytes) generated by EiffelStudio.5 The 10 programs include 7 applications and 3 libraries; all D. Object-Oriented Encapsulation of them are widely-used in Linux and other “*nix” distribu- Externals. For every included system header header.h, tions. hello world is the only toy application, which is T defines a class HEADER with wrappers for all external however useful as baseline of translating from C to Eiffel with functions and variables declared in header.h. The wrappers C2Eif. The other applications are: micro httpd 12dec2005, are routines using the external mechanism and performing the a minimal HTTP server; xeyes 1.0.1, a widget for the X necessary conversions between the Eiffel and the C runtimes. Windows System that shows two googly eyes following the In particular, external functions using only numeric types, cursor movements; less 382-1, a text terminal pager; wget which are interoperable between C and Eiffel, directly map 1.12, a command-line utility to retrieve content from the web; to wrapper routines; for example, exit in stdlib.h is: links 1.00, a simple web browser; vim 7.3, a powerful text editor. The libraries are: libcurl 7.21.2, a URL-based exit (status: INTEGER 32) external C inline use
Table I shows data about 10 C open-source programs and 5We do not give a binary size for libraries, because EiffelStudio cannot a testsuite translated to Eiffel with C2Eif running on a compile them without a client. SIZE (LOCS)#EIFFEL TRANSLATION BINARY SIZE CILEIFFEL CLASSES (S)(MB) hello world 8 15 1 1 1.3 micro httpd 565 1,934 16 1 1.5 xeyes 1,463 10,661 78 1 1.8 less 16,955 22,545 75 5 2.6 wget 46,528 57,702 183 25 4.5 links 70,980 100,815 211 33 13.9 vim 276,635 395,094 663 144 24.2 libcurl 37,836 65,070 289 18 – libgmp 61,442 79,971 370 21 – libgsl 238,080 344,115 978 85 – gcc (torture) 147,545 256,246 2,569 79 1,576 TOTAL 898,037 1,334,168 5,433 413 1,626
TABLE I TRANSLATION OF 10 OPEN-SOURCEPROGRAMSANDATESTSUITE.
a copy-paste error rather than a feature. 2 tests exercise GCC- The test with wget downloaded the same 174 MB Eclipse specific optimizations, which are immaterial after translation package over the SWITCH Swiss network backbone. The to Eiffel. 6 tests target somehow exotic GCC built-in func- bottleneck is the network bandwidth, hence differences in tions, such as builtin frame address; 1 test performs explicit performance are negligible, except for memory consumption, function alignment; and 3 rely on special bitfield operations. which is higher in Eiffel due to garbage collection (memory is deallocated only when necessary, hence the maximum memory B. Performance usage is higher in operational conditions). The test with libcurl consisted in running all 583 tests Table II shows the result of trials that analyze the performance from the standard testsuite mentioned before. The total runtime of 6 of the programs, plus the GCC torture testsuite, running is comparable in translated Eiffel and C. on the same system as Table I. For each program or test- The tests with libgmp and libgsl ran their respective suite, Table II reports the execution time (in seconds), the standard testsuites. The overall slow-down seems significant, maximum percentage of CPU and the maximum amount of but a closer look shows that the large majority of tests run in RAM (in MBytes) used while running. The table compares the comparable time in C and Eiffel: 30% of the libgmp tests performance of the original C versions (column C) against the take up over 95% of the running time; and 26% of the libgsl Eiffel translations with C2Eif (column T), and, for the simpler tests take up almost 99% of the time. The GCC torture tests examples, against manually written Eiffel implementations incur only a moderate slow-down, concentrated in 3 tests (column E) that transliterate the original C implementations that take 97% of the time. In all these experiments, the tests using the closest Eiffel constructs (for example, putchar be- responsible for the conspicuous slow-down target operations comes Io.put character) with as little changes as possible that execute slightly slower in the translated Eiffel than in the to the code structure. Maximum CPU and RAM usages are native C (e.g., accessing a struct field) and repeat it a huge immaterial for the libraries and for the GCC testsuite, because number of times, so that the basic slow-down increases many- their execution consisted of a large number of separate calls. fold. These bottlenecks are an issue only in a small fraction hello world The performance of demonstrates the base of the tests and could be removed manually in the translation. overhead, in terms of CPU and memory usage, of the de- Finally, the interactive applications (xeyes, less, links, fault Eiffel runtime (objects, automatic memory management, and vim) run smoothly with good responsiveness comparable and contract checking—which can however be disabled for to their original implementations. applications where sheer performance is more important than In all, the performance overhead in switching from C to having additional checks). Eiffel significantly varies with the program type but, even The test with micro httpd consisted in serving the local when it is noticeable, it does not preclude the usability of download of a 174 MB file (the Eclipse IDE); this test boils the translated application or library in normal conditions (as down to a very long sequence (approximately 200 million opposed to the behavior in a few specific test cases). iterations) of inputting a character from file and outputting it to standard output. The translated Eiffel version incurs a C. Safety and Debuggability significant overhead with respect to the original C version, What are the benefits of automatically porting C code to but it is faster than the manually written Eiffel implementation. Eiffel? One obvious advantage is the reusability of the huge This might be due to feature lookups in Eiffel or to the less C code base. This section demonstrates that the higher-level optimized implementation of Eiffel’s character services. As a features of Eiffel can bring other benefits, in terms of improved side note, we did the same exercise of manually transliterat- safety and easier debugging of applications automatically ing micro httpd using Java’s standard libraries; this Java generated using C2Eif. translation ran the download example in 170 seconds, using Uncontrolled format string is a well-known vulnerabil- up to 99% of CPU and 150 MB of RAM. ity [10] of C’s printf library function, which permits malicious EXECUTIONTIME (S)MAX %CPUMAX MBRAM CTE CTE CTE hello world 0 0 0 0 30 30 1.3 5.5 5.3 micro httpd 5 37 46 99 99 99 2.3 7.8 5.6 wget 16 16 – 22 22 – 4.4 69 – libcurl 199 212 – ––– ––– libgmp 44 728 – ––– ––– libgsl 25 1501 – ––– ––– gcc (torture) 0 5 – ––– –––
TABLE II PERFORMANCECOMPARISONFOR 3 OPEN-SOURCE APPLICATIONS AND 4 TESTSUITES.
clients to access data in the stack by supplying special format String envval should have been passed to fprintf instead of strings. Consider for example the C program: long repfactor. GCC with standard compilation options does
int main (int argc, char ∗ argv[]) not detect this error, which may produce garbage or even { char ∗secret = ”This is secret!”; crash the program at runtime. Interestingly, version 5.0.2 of if (argc >1) printf(argv[1]); return 0; } libgmp patches the code in the wrong way, changing the format specifier into . This is still incorrect If we call it with ./a.out "{Stack: %x%x%x%x%x%x} -> %s", we ”%s” ”%ld” because when envval does not encode a valid “repfactor”, get the output {stack: 0b7[...]469} -> This is secret!, which reveals the local string secret. The safe way to achieve the outcome of the conversion into long is unpredictable. the intended behavior is printf (”%s”, argv[1]) instead of Finally, notice that C2Eif may also report false positives, such v printf v printf (argv[1]), so that the input string is interpreted literally. as long = ”Hello!”; (”%s”, ) which is acceptable What is the behavior of code vulnerable to uncontrolled (though probably not commendable) usage. C arrays translate to in- format strings, when translated to Eiffel with C2Eif? In Out-of-bound error detection. stances of class CE ARRAY (see Section III-A), which in- simple usages of printf with just one argument as in the cludes contracts that signal out-of-bound accesses to the example, the translation replaces calls to printf with calls array content. Therefore, out-of-bound errors are much easier to Eiffel’s Io.put string, which prints strings verbatim with- to detect in Eiffel applications using components translated out interpreting them; therefore, the translated code is not with C2Eif. Simply by translating and running the libgmp vulnerable in these cases. The replacement was possible in testsuite, we found an off-by-one error causing out-of-bound 65% of all the printf calls in the programs of Table I. C2Eif access (our patch is included in the latest library version); translates more complex usages of printf (for example, with the error does not manifest itself when running the original more than one argument and no literal format string such as C version. More generally, contracts help detect the precise printf (argv[1], argv[2])) into wrapped calls to the external location of array access errors. Consider, for example: printf function, hence the vulnerability still exists. However, it /∗ 1 ∗/ int ∗ buf = (int ∗) malloc(sizeof (long long int) ∗ 10); is less extensive or more difficult to exploit in Eiffel: primitive /∗ 2 ∗/ buf = buf − 10; types (such as numeric types) are stored on the stack in Eiffel /∗ 3 ∗/ buf = buf + 29; /∗ 4 ∗/ ∗buf = ’a’; buf++; as they are in C, but Eiffel’s bulkier runtime typically stores /∗ 5 ∗/ ∗buf = ’b’; them farther up the stack, hence longer and more complex buf is an array that stores 20 elements of type (which format strings must be supplied to reach the stack data (for int has half the size of ). The error is on line 5, instance, a variation of the example with secret requires 386 long long int when buf points to position 20, out of the array bounds; line %x in the format string to reach local variables). On the other 2 is instead OK: buf points to an invalid location, but it is hand, non-primitive types (such as strings and structs) are not written to. This program executes without errors in C; the wrapped by Eiffel classes in C2Eif, which are stored in the Eiffel translation, instead, stops exactly at line 5 and signals heap, hence unreachable directly by reaching stack data. In an out-of-bound access to buf. these cases, the vulnerability vanishes in the Eiffel translation. Array bound checking may be disabled, which is necessary Debugging format strings. C2Eif also parses literal format in borderline situations where out-of-bound accesses do strings passed to printf and detects type mismatches between not crash because they assume a precise memory layout. format specifiers and actual arguments. This analysis, neces- For example, links and vim use statements of the sary when moving from C to a language with a stronger type form block ∗p = (block ∗)malloc(sizeof(struct block)+ len), system, helps debug incorrect and potentially unsafe usages with len >0, to allocate struct datatypes of the form of format strings. Indeed, a mismatch detected while running struct block { /∗... ∗/char b[1]; }. In this case, p points the 145 libgmp tests revealed a real error in the library’s to a struct with room for 1 + len characters in p→b; the implementation of macro TESTS REPS: instruction p→b[len]=‘i’ is then executed correctly in C, char ∗envval, ∗end;/∗ ... ∗/ but the Eiffel translation assumes p→b has the statically long repfactor = strtol(envval,&end, 0); if(∗end || repfactor ≤ 0) fprintf (stderr, ”Invalid repfactor: %s.\n”, repfactor); declared size 1, hence it stops with an error. Another borderline situation is with multi-dimensional arrays, such as double a[2][3]. An iteration over a’s six elements with programming languages such as old versions of COBOL [14], double ∗p = &a[0][0] translated to Eiffel fails to go past the [15], Fortran-77 [16], [17], and K&R C [18]. third element, because it sees a[0][0] as the first element of Some translators focus on the adaptation of code into an ex- an array of length 3 (followed by another array of the same tension (superset) of the original language. Examples include length). A simple cast double ∗ p = (double∗)a achieves the the migration of legacy code to object-oriented code, such as desired result without fooling the compiler, hence it works Cobol to OO-Cobol [19], [20], [21], Ada to Ada95 [22], and without errors also in translated code. These situations are C to C++ [23], [24]. Some of such efforts try to go beyond the examples of unsafe programming more often than not. mere hosting of the original code, and introduce refactorings More safety in Eiffel. Our experiments found another that take advantage of the object-oriented paradigm. Most bug in libgmp, where function gmp sprintf final had three of these refactorings are, however, limited to restructuring formal input arguments, but was only called with one ac- modules into classes. C2Eif follows a similar approach, but tual through a function pointer. Inspection suggests it is a it also takes advantage of some advanced features (such as copy-paste error of the other function gmp sprintf reps. The contracts) to improve the reliability of translated code. Eiffel version found the mismatch when calling the routine Ephedra [25] is a tool that translates legacy C to Java. and reported a contract violation. Easily finding such bugs It first translates K&R C to ANSI C; then, it maps data demonstrates the positive side-effects of translating widely- types and type casts; finally, it translate the C source code to used C programs into a tighter, higher-level language. Java. Ephedra handles a significant subset of C, but it cannot D. Limitations translate frequently used features such as unrestricted gotos, The only significant limitations of the translation T imple- external pre-compiled libraries, and inlined assembly code. mented in C2Eif in supporting C programs originate in the A case study evaluating Ephedra [26] involved three small fprintf introduction of strong typing: programming practices that programs: the implementation of , a monopoly game implicitly rely on a certain memory layout may not work in (about 3 KLOC), and two graph layout algorithms. The study C applications translated to Eiffel. Section IV-C mentioned reports that the source programs had to be manually adapted to some examples in the context of array manipulation (where, be processable by Ephedra. By contrast, C2Eif is completely however, the checks on the Eiffel side can be disabled). An- automatic, and it works with significantly larger programs. other example is a function int trick (int a, int b) that returns Other tools (proprietary or open-source) to translate C its second argument through a pointer to the stack, with the (and C++) to Java or C# include: C2J++ [27], C2J [28], instructions int ∗p = &a; return ∗(p+1). C2Eif’s translation and C++2C# and C++2Java [29]. Table III shows a feature assumes p points to a single integer cell and cannot guarantee comparison among the currently available tools that translate that b is stored in the next cell. C to an object-oriented language, showing: Another limitation is the fact that C2Eif takes input from • The target language. CIL, hence it does not support legacy C such as K&R C. The • Whether the tool is completely automatic, that is whether support can, however, be implemented by directly extending it generates translations that are ready for compilation. the pre-processing CIL front-end. Similarly, the GCC torture • Whether the tool is available for download and usable. testsuite highlighted a few exotic GCC features currently In a couple of cases we could only find papers describing unsupported by C2Eif (Section IV-B), which may be handled the tool but not a version of the implementation working in future work. on standard machines. V. RELATED WORK • An (subjective to a certain extent) assessment of the readability of the code produced. In each case, we tried There are two main approaches to reuse source code written to evaluate if the translated code is sufficiently simi- in a “foreign” language (e.g., C) in a different “host” language lar to the C source to be readily understandable by a (e.g., Eiffel): define wrappers for the components written in programmer familiar with the latter. We judged C2J’s the foreign language; and translate the foreign source code readability negatively because the tool puts data into a into functionally equivalent host code. single global array to support pointer arithmetic. This is Wrapping foreign code. Wrappers enable the reuse of for- quite detrimental to readability and also circumvents type eign implementations through the API of bridge libraries. This checking in the Java translation. approach (e.g., [11], [12], [13]) does not modify the foreign • Whether the tool supports unrestricted calls to exter- code, whose functionality is therefore not altered; moreover, nal libraries, unrestricted pointer arithmetic, unrestricted the complete foreign language is supported. On the other hand, s, and inlined assembly code. the type of data that can be retrieved through the bridging API goto is often restricted to a simple subset common to the host and The table demonstrates that C2Eif is arguably the first com- foreign language (e.g., primitive types). C2Eif uses wrappers pletely automatic tool that handles the complete C language only to translate external functions and assembly code. and produces readable object-oriented code. Translating foreign code. Industrial practices have long In previous work, we developed J2Eif, an automatic source- encompassed manual migrations of legacy code. Some semi- to-source translator from Java to Eiffel [30]; translating be- automated tools exist that help translate code written in legacy tween two object-oriented languages does not pose some of the T rn Ojc-retdregneigenvironment”. reengineering “Object-oriented grant ETH equivalents. Eiffel their implementations with structure tables) data separation hash C (e.g., command/query replacing and attributes, [2], practices class routine re-factoring into inheritance, of arguments usage to classes, of translated into encapsulation code sophisticated globals more C investigate of will We re-engineering Eiffel. improved be by object-oriented to the aspect generated which Another is comments, translation. code in preserve lost not Eiffel therefore does are the CIL example, of sometimes For is C2Eif. readability which to analysis, particular, program in detrimental for CIL, code code. the generated optimizes the of maintainability and safer. is that features significant code advanced Eiffel’s produce of of some to of libraries advantage takes and correctly and C2Eif size, applications that showed complete paper translates the tool available in freely Experiments the into C2Eif. implementation applications its C and Eiffel, of translation into complete the presented paper This C translation. in rigorous errors a finds of effect” also “side which formal a Rosu’s [4], as and C program Ellison of with semantics similarity executable a little a has shares C2Eif This debuggability [34]. and safety errors improved as offers type it or as format scope, [33], different of [32], detection other errors example, and memory accesses for array out-of-bound code; [31], vulnerability C string existing of safety with. deal to abstraction had different C2Eif wildly which bridging levels, of problems formidable J shne,C .Fra .Nri,adB ee,“sbeveri- “Usable Meyer, B. and Nordio, M. Furia, A. C. Tschannen, J. Intermediate [6] “CIL: with Weimer, W. C and of Rahul, S. semantics McPeak, S. formal Necula, executable C. “An G. Rosu, [5] G. and Ellison 2011. C. http://lang-index.sourceforge.net, Index, Popularity [4] Language The [3] Meyer, B. in [2] language,” C the of development “The Ritchie, D. [1] Acknowledgements. work. Future C. Safer side-benefits C++2C# C++2Java C2J C2J++ Ephedra C2Eif cto fojc-retdporm ycmiigsai n dynamic and static combining by in programs techniques,” object-oriented of fication Programs,” C of Transformation and Analysis in for Tools and Language in applications,” 1997. Hall, Preprints (HOPL-II) Conference Languages ming ofrneo ople Construction Compilier on Conference I C VI. T aytcnqe xs ie taeirtn the ameliorating at aimed exist techniques Many OSTRANSLATING OOLS betOine otaeConstruction Software Object-Oriented iflysyes yes Eiffel aan yes yes no no no no no Java no Java Java Java #n yes no C# fatmtclyprigCporm oEiffel. to programs C porting automatically of
NLSOSAND ONCLUSIONS target SEFM POPL
uuewr ilipoetereadability the improve will work Future language e.LC,vl 01 01 p 382–398. pp. 2011, 7041, vol. LNCS, ser. ,
02 p 533–544. pp. 2012, , completely R hswr a atal upre by supported partially was work This automatic EFERENCES AL III TABLE available C TO − + + + + + readability O-O F UTURE e e e yes yes yes yes 02 p 213–228. pp. 2002, , on ono no no no no no no no no no no no yes no no no no no no no external LANGUAGES libraries
93 p 201–208. pp. 1993, , pointer W n d Prentice ed. 2nd , itr fProgram- of History arithmetic ORK . gotos
inlined assembly Nvsf,“2:aCt aatasao, http://www.novosoft-us.com/ translator,” Java to C a “C2J: Novosoft, [28] in Java,” to C++ “Translating Tilevich, E. in experiences,” [27] migration Java to “C ——, M [26] A. procedural H. migrating and for Martin framework J. “A Kontogiannis, [25] K. in and identification Zou object Y. driven “Evidence [24] Patil, P. and Kontogiannis K. in programs,” [23] ada legacy from objects 95 ada of “Extracting identification Sward, the for R. “Scenarios Fielt, [22] E. and Bosma, an H. Wiggerts, in T. programs [21] Cobol oriented object- procedurally into of procedural “Migration “Reengineering Sneed, H. Kotik, data [20] G. abstract and “Recovering Newcomb Reubenstein, P. H. [19] and from Harris, model object D. an Yeh, “Deriving Byrne, A. J. [18] E. and Subramaniam V. from G. designs object-oriented [17] “Creating Carver, L. D. and Achee L. B. in recycling,” [16] Java to Cobol “Automated conversions,” Mossienko, language M. of realities [15] and “The Verhoef, C. Guerra, and Terekhov legacy A. P. “Reengineering A. Oca, Fasolino, de [14] M. R. C. and Carver, A. L. D. Lucca, Serrano, A. D. M. A. [13] G. with Lucia, legacy “Saving de Gracer, F. A. and Nackman, [12] R. L. http://cwe.mitre.org/data/ Jr., Dietrich, string,” C. W. format [11] “Uncontrolled CWE-134, [10] G .Ncl,S cek n .Wie,“Crd type-safe “CCured: Weimer, W. and McPeak, S. Necula, heavyweight C. for framework G. a “Valgrind: [34] Seward, J. and Nethercote N. [33] compiler,” ANSI-C full memory-safe the of “Implementation Oiwa, Y. [32] from protection Automatic “FormatGuard: Cowan, C. [31] translation “Automated Nordio, M. and Furia, A. C. Oriol, M. http://www. Trudel, Java,” M. to C++ [30] and C# to “C++ Solutions, Software Tangible [29] D ae,“nfl theorems,” folk “On Harel, D. [9] M rdl .A ui,adM odo AtmtcCt - translation O-O to C “Automatic Nordio, M. and Furia, A. C. Trudel, “AutomaticM. Oriol, M. [8] and Meyer, B. Nordio, M. Furia, A. C. Trudel, M. [7] solutions/product Press 1997. Microsystems Society, Sun Journal, Conference opers’ 143–153. pp. 2002, Society, in in platforms,” object-oriented to code in code,” procedural 65–77. pp. Llamos 2004, A. Springer, Science, 2004 Computer Ada-Europe in - Technologies Software Reliable in systems,” legacy in objects 116. in architecture,” object-oriented in systems,” language,” oriented procedural conventional a from instances in object and types code,” Fortran legacy 1997. 179–194, pp. 2, no. code,” FORTRAN legacy 40–50. pp. 2003, Software IEEE 2002. 37–55, environments,” distributed for systems plat- object-oriented towards systems legacy forms,” “Migrating Petruzzelli, S. objects,” definitions/134.html. 1980. 389, ihCEfe, in C2Eiffel,” with http://arxiv.org/abs/1206.5648, Eiffel,” to code 2012. source June C of translation erfitn flgc oe”in code,” legacy of retrofitting in instrumentation,” binary dynamic 259–269. pp. 2009, ACM, USA: implementation and design language in Symposium in vulnerabilities,” string 20–35. in pp. Eiffel,” to 2011, code source Java of tangiblesoftwaresolutions.com/. rceig fte20 C IPA ofrneo Programming on conference SIGPLAN ACM 2009 the of Proceedings CSMR WCRE rc fICSM of Proc. EECmue oit,20,p.200–210. pp. 2001, Society, Computer IEEE . IPA Not. SIGPLAN 95 p 227–236. pp. 1995, , 2001. , o.1,n.6 p 1–2,2000. 111–124, pp. 6, no. 17, vol. , 2.hm,2001. c2j.shtml, WCRE STEP WCRE ICSM p 2–2,1997. 122–129, pp. , le,“taeisfrmgainfo oJava,” to C from migration for “Strategies uller, ¨ o.2,n.1,p.7–3 1989. 77–83, pp. 10, no. 24, vol. , 02 oldmntainpaper. demonstration tool 2012, , 99 p 12–21. pp. 1999, , rceig fte1t SNXSecurity USENIX 10th the of Proceedings ora fSsesadSoftware and Systems of Journal p –2 1996. 3–12, pp. , 95 p 237–249. pp. 1995, , WCRE omn ACM Commun. POPL otaeMaintenance Software OL Europe TOOLS ´ n .Srhee,Es,vl 3063. vol. Eds., Strohmeier, A. and ı PLDI e.PD 0.NwYr,NY, York, New ’09. PLDI ser. , 02 p 128–139. pp. 2002, , 97 p 24–32. pp. 1997, , APSEC .Ss.Softw. Syst. J. 07 p 89–100. pp. 2007, , is emnJv Devel- Java German First CSMR 01 p 390–399. pp. 2001, , o.2,n.7 p 379– pp. 7, no. 23, vol. , e.LC,vl 6705, vol. LNCS, ser. , e.LcueNotes Lecture ser. , EEComputer IEEE . EEComputer IEEE . o.6,n.1 pp. 1, no. 64, vol. , 92 p 105– pp. 1992, , printf CSMR o.39, vol. , IEEE, . format