11 Known Bugs and Limitations

11.1 Code that CIL won’t compile

• We do not support tri-graph sequences (ISO 5.2.1.1).
• CIL cannot parse arbitrary #pragma directives. Their syntax must follow gcc’s attribute syntax to be understood. If you need a pragma that does not follow gcc syntax, add that pragma’s name to no_parse_pragma in src/frontc/clexer.mll to indicate that CIL should treat that pragma as a monolithic string rather than try to parse its arguments.

  CIL cannot parse a line containing an empty #pragma.

• CIL only parses #pragma directives at the "top level", this is, outside of any enum, structure, union, or function definitions.

  If your compiler uses pragmas in places other than the top-level, you may have to preprocess the sources in a special way (sed, perl, etc.) to remove pragmas from these locations.

• CIL cannot parse the following code (fixing this problem would require extensive hacking of the LALR grammar):

  int bar(int ()); // This prototype cannot be parsed
  int bar(int x()); // If you add a name to the function, it works
  int bar(int (*)()); // This also works (and it is more appropriate)
  

• CIL also cannot parse certain K&R old-style prototypes with missing return type:

  g(); // This cannot be parsed
  int g(); // This is Ok
  

• CIL does not understand some obscure combinations of type specifiers (“signed” and “unsigned” applied to typedefs that themselves contain a sign specification; you could argue that this should not be allowed anyway):

  typedef signed char __s8;
  __s8 unsigned uchartest; // This is unsigned char for gcc
  

• CIL does not support constant-folding of floating-point values, because it is difficult to simulate the behavior of various C floating-point implementations in Ocaml. Therefore, code such as this will not compile:

  int globalArray[(1.0 < 2.0) ? 5 : 50]
  

• CIL uses Ocaml ints to represent the size of an object. Therefore, it can’t compute the size of any object that is larger than 2³⁰ bits (134 MB) on 32-bit computers, or 2⁶² bits on 64-bit computers.

11.2 Code that behaves differently under CIL

• Without optimizations GCC generally does not use “inline” functions. With optimizations they might be inlined. CIL assumes optimization, and also assumes that “inline” functions are always inlined.
• GCC has a strange feature called “extern inline”. Such a function can be defined twice: first with the “extern inline” specifier and the second time without it. If optimizations are turned off then the “extern inline” definition is considered a prototype (its body is ignored).

  With old versions of gcc, if optimizations are turned on then the extern inline function is inlined at all of its occurrences from the point of its definition all the way to the point where the (optional) second definition appears. No body is generated for an extern inline function. A body is generated for the real definition and that one is used in the rest of the file.

  With new versions of gcc, the extern inline function is used only if there is no actual (non-extern) second definition (i.e. the second definition is used in the whole file, even for calls between the extern inline definition and the second definition).

  By default, CIL follows the current gcc behavior for extern inline. However, if you set oldstyleExternInline to true, you will get an emulation of gcc’s old behaviour (under the assumption that optimizations are enabled): CIL will rename your extern inline function (and its uses) with the suffix __extinline. This means that if you have two such definition, that do different things and the optimizations are not on, then the CIL version might compute a different answer! Also, if you have multiple extern inline declarations then CIL will ignore but the first one. This is not so bad because GCC itself would not like it.

• The implementation of bitsSizeOf does not take into account the packing pragmas. However it was tested to be accurate on cygwin/gcc-2.95.3, Linux/gcc-2.95.3.
• -malign-double is ignored.
• The statement x = 3 + x ++ will perform the increment of x before the assignment, while gcc delays the increment after the assignment. It turned out that this behavior is much easier to implement than gcc’s one, and either way is correct (since the behavior is unspecified in this case). Similarly, if you write x = x ++; then CIL will perform the increment before the assignment, whereas GCC will perform it after the assignment.
• Because CIL uses 64-bit floating point numbers in its internal representation of floating point numbers, long double constants are parsed as if they were double constants.

11.3 Effects of the CIL translation

• CIL cleans up C code in various ways that may suppress compiler warnings. For example, CIL will add casts where they are needed while gcc might print a warning for the missing cast. It is not a goal of CIL to emit such warnings — we support several versions of several different compilers, and mimicking the warnings of each is simply not possible. If you want to see compiler warnings, compile your program with your favorite compiler before using CIL.
• In the new versions of glibc there is a function __builtin_va_arg that takes a type as its second argument. CIL handles that through a slight trick. As it parses the function it changes a call like:

    mytype x = __builtin_va_arg(marker, mytype)
  

  into

   mytype x;
   __builtin_va_arg(marker, sizeof(mytype), &x);
  

  The latter form is used internally in CIL. However, the CIL pretty printer will try to emit the original code.

  Similarly, __builtin_types_compatible_p(t1, t2), which takes types as arguments, is represented internally as __builtin_types_compatible_p(sizeof t1, sizeof t2), but the sizeofs are removed when printing.