Menu

#6 disappearing externs

Feature request
closed-wont-fix
nobody
5
2005-11-21
2005-08-26
No

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) ->

Discussion

  • Matt Harren

    Matt Harren - 2005-08-26

    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.

     
  • Matt Harren

    Matt Harren - 2005-11-21
    • status: open --> closed
     
  • Matt Harren

    Matt Harren - 2005-11-21
    • status: closed --> closed-wont-fix
     
  • Matt Harren

    Matt Harren - 2005-11-21

    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.

     

Log in to post a comment.