About the generated C code

People who want or have to code part of their applications and/or libraries in C should really limit themselves to the clean interfaces provided by Cecil or the external mechanism. This page mentions some facts you should be aware of before you start.

Generated type names

First and above all, SmallEiffel generates one unique type name in the C code for each living type present in the Eiffel code. This type is of the form `Txyz` where `xyz` represents the number corresponding to the name of the type, including its parameters in the case of generic types. (More details about this in our research papers). When you compile your application, you can find them in a mangling table, somewhere in the C code, which looks like this:

    D 2  T1489 R BOOLEAN_CONSTANT 210,253
    A 1  T945  R BIT_CONSTANT 945
    A*1  T218  R TAG_NAME 218
    A 1  T602  R TYPE_BIT_1 602

But don't use this information ! The mangling table is only valid for one specific compilation of one specific application with one specific compiler and specific libraries...

Indeed, when computing a type code, collisions may occur, and affect this process. Thus, the number (and name) corresponding to each type depends not only on the type name, but also on the order in which they are compiled. That is, on the application and libraries compiled... They also depend on the compilation mode used, and the version of the compiler you're using. So what is `T145` now may become `T234` the next time you compile...

Consequently, do not, ever, rely on the type numbers in the generated C code, because they are not constant ! (Except for a few ones which have a fixed, hard-coded name). So don't bother writing in your own C code things such as `new123` or `T456`, because the only thing we guarantee in this case is that your code shall break one day or another...

The mangling table

OK, so now you understand why you cannot use type numbers, but you still want to know what those things in the mangling table mean. :)

First, a big caveat. Although it hasn't changed a lot and has been very stable for quite some time now, the mangling table coding may change in the future ! As I'm writing these lines, we have no plans to change it, and we prefer keeping it the way it is. But once again, we do not commit ourselves to the current representation.

Here is excerpts of a mangling table which cover all the possible cases (taken from some `compile_to_c.h`):

    A 1  T220  R E_DEBUG 220
    A 6  T326  R FIXED_ARRAY[RUN_FEATURE] 389,384,367,352,326,53
    D 2  T166  R BOOLEAN_CONSTANT 169,168
    A*1  T215  R E_ENSURE 215
    A 1  T37   E NATIVE_ARRAY[STRING] 37

Each mangling table entry comprises 7 fields:

Liveness
  The first field shows whether the type is Dead or (A)Live, that is whether instances of this type are ever created at run-time. (Ok, it should have been L, instead of A...)
Tagless
  When the second character on a line is a star `*`, it marks an untagged type, that is a type on which there is no late binding but only static calls. Note that the type inference algorithm used in SmallEiffel increases the number of such types.
# of live subtypes
  Number of concrete, live descendants of the type (including itself). It is thus the number of items in the last field.
Type mangled name
  The type name in the C code. As explained above, the ID number varies.
Reference
  Is the type a Reference or an Expanded one?
Full type name
  Self-explanatory...
Live subtypes list
  A comma-separated list of type IDs listing all the live descendants of the current type (including itself, if it is a live one).

Copyright © Dominique COLNET and Suzanne COLLIN - <colnet@loria.fr>
Last update: 05 May 1999, by OZ.