Consider:
extern int x;
int x = 0;
This is simple and normal and legal both as C and as
C++, but CIL
turns it into
int x;
int x = 0;
which is legal in standard C, but is no longer valid
C++ and may
confuse some C compilers. I think it would be better if
CIL kept the
"extern" in cases like this.
The following patch solves some of the problems I've
been having while
using CIL to preprocess C code for a C++ compiler, but
I haven't yet
investigated very much whether it breaks something else.
--- src/cil.ml (revision 405)
+++ src/cil.ml (working copy)
@@ -3420,7 +3420,11 @@
(* print global variable 'extern' declarations,
and function prototypes *)
| GVarDecl (vi, l) ->
self#pLineDirective l ++
- (self#pVDecl () vi)
+ (self#pVDecl () (match vi.vtype with
+ TFun(_, _, _, _) -> vi
+ | _ -> (if vi.vstorage = NoStorage
+ then {vi with vstorage = Extern}
+ else vi)))
++ text ";\n"
| GAsm (s, l) ->
Logged In: YES
user_id=1278428
I don't actually know what part of CIL causes this, and I
won't have time to look at this for a little bit. Note that
the "canonicalize" extension will fix some differences
between C and C++, and it correctly handles your example by
readding "extern" to the first declaration.
Logged In: YES
user_id=1278428
I'm not sure it's worth changing the parser for the sake of
C++ ... use canonicalize instead. Closing the bug.