utility to intentionally mangle function names?

Discussion in 'C Programming' started by Eric, Apr 7, 2004.

  1. Eric

    Eric Guest

    I've got a pretty large C program with global variables and function
    names strewn about (i.e. no "static" declarations in front of them).
    Now I want to expose the ability for user's to supply their own shared
    object / dll code which will link with my large ugly program.
    Problem: naming collisions.

    If my program has:

    void common_function_name (void)
    {
    ....
    }

    and now the caller has a similar function, they will get a link error.

    What I really would like to do is "mangle" all of my names
    intentionally, once I've built my code, except for those few functions
    that are legitimate entry points back into my code that the caller
    will need.

    Thought about wrapping all my code in a namespace and compiling in C++
    but this doesn't appear feasible now that I've tried it (many errors).
    The other method would be to do a bunch of code conversion, which is
    highly risky.

    Thoughts?
     
    Eric, Apr 7, 2004
    #1
    1. Advertising

  2. Eric

    Eric Sosman Guest

    Eric wrote:
    >
    > I've got a pretty large C program with global variables and function
    > names strewn about (i.e. no "static" declarations in front of them).
    > Now I want to expose the ability for user's to supply their own shared
    > object / dll code which will link with my large ugly program.
    > Problem: naming collisions.
    >
    > If my program has:
    >
    > void common_function_name (void)
    > {
    > ...
    > }
    >
    > and now the caller has a similar function, they will get a link error.
    >
    > What I really would like to do is "mangle" all of my names
    > intentionally, once I've built my code, except for those few functions
    > that are legitimate entry points back into my code that the caller
    > will need.
    >
    > Thought about wrapping all my code in a namespace and compiling in C++
    > but this doesn't appear feasible now that I've tried it (many errors).
    > The other method would be to do a bunch of code conversion, which is
    > highly risky.
    >
    > Thoughts?


    First thought: I hope you've now learned the drawbacks
    of wholesale namespace pollution.

    Second thought: Gather up all the objectionable names
    (using ad-hoc tools -- a good place to start might be by
    examining your executable's symbol table, if it has one)
    and then build yourself a "mangle.h" header file:

    #define common_function_name mangled_function_name
    #define common_variable_name mangled_variable_name
    ...

    #include this header at the start of each source file,
    recompile, and clean up the (few, one hopes) problems.

    Third thought: The success of the above approach depends
    on your ability to dream up mangled names nobody else will
    ever invent. That's a pretty high standard of originality,
    and may even create problems where none existed before.
    What you really need to do is reduce the size of the problem
    (you can't eliminate it entirely) by hiding the names you
    really didn't need to export in the first place. The C way
    to do this is to go around sticking in `static', and the
    same ad-hoc methods you used to collect the offending symbols
    for "mangle.h" would also serve as a help for locating all
    the right sites for `static'. Alternatively, your platform
    may offer a non-C means of hiding externally-linked symbols,
    typically after linking a library; consult your documentation.

    Fourth thought: There really is no 100% reliable Standard
    C solution to this problem, even if the code was designed from
    the very beginning to be minimally intrusive of the name space.

    --
     
    Eric Sosman, Apr 7, 2004
    #2
    1. Advertising

  3. Eric

    Alan Balmer Guest

    On 7 Apr 2004 07:41:45 -0700, (Eric) wrote:

    >I've got a pretty large C program with global variables and function
    >names strewn about (i.e. no "static" declarations in front of them).
    >Now I want to expose the ability for user's to supply their own shared
    >object / dll code which will link with my large ugly program.
    >Problem: naming collisions.
    >
    >If my program has:
    >
    >void common_function_name (void)
    >{
    >...
    >}
    >
    >and now the caller has a similar function, they will get a link error.
    >
    >What I really would like to do is "mangle" all of my names
    >intentionally, once I've built my code, except for those few functions
    >that are legitimate entry points back into my code that the caller
    >will need.


    Rather than "mangle" them, why not make them static? If you can
    identify them for the purpose of "mangling", surely it's easier to do
    it right.
    >
    >Thought about wrapping all my code in a namespace and compiling in C++
    >but this doesn't appear feasible now that I've tried it (many errors).
    > The other method would be to do a bunch of code conversion, which is
    >highly risky.
    >
    >Thoughts?


    --
    Al Balmer
    Balmer Consulting
     
    Alan Balmer, Apr 7, 2004
    #3
  4. Eric

    Dan Pop Guest

    In <> (Eric) writes:

    >I've got a pretty large C program with global variables and function
    >names strewn about (i.e. no "static" declarations in front of them).
    >Now I want to expose the ability for user's to supply their own shared
    >object / dll code which will link with my large ugly program.
    >Problem: naming collisions.
    >
    >If my program has:
    >
    >void common_function_name (void)
    >{
    >...
    >}
    >
    >and now the caller has a similar function, they will get a link error.
    >
    >What I really would like to do is "mangle" all of my names
    >intentionally, once I've built my code, except for those few functions
    >that are legitimate entry points back into my code that the caller
    >will need.
    >
    >Thought about wrapping all my code in a namespace and compiling in C++
    >but this doesn't appear feasible now that I've tried it (many errors).


    That's the right idea, you just have to implement it in C. Create your
    own name space, by prefixing all the internal identifiers with a prefix
    of your choice, carefully chosen to avoid likely conflicts with other
    programs doing the same thing. Make a list of all the identifiers that
    need to be "mangled" and a simple script around a non-interactive text
    editor should solve your problem.

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, Apr 7, 2004
    #4
  5. In article <c51d92$35b$>, Dan Pop wrote:
    > In <> (Eric) writes:
    >
    >>I've got a pretty large C program with global variables and function
    >>names strewn about (i.e. no "static" declarations in front of them).
    >>Problem: naming collisions.
    >>
    >>What I really would like to do is "mangle" all of my names
    >>intentionally, once I've built my code, except for those few functions
    >>that are legitimate entry points back into my code that the caller
    >>will need.

    >
    > That's the right idea, you just have to implement it in C. Create your
    > own name space, by prefixing all the internal identifiers with a prefix
    > of your choice, carefully chosen to avoid likely conflicts with other
    > programs doing the same thing. Make a list of all the identifiers that
    > need to be "mangled" and a simple script around a non-interactive text
    > editor should solve your problem.


    If all your code #includes a header file, you could get
    away without mangling your source code, and mangle it
    transparently in the preprocessor instead.
    For every global identifier that you don't want exported,

    #define common_function1 app_specific_common_function1
    #define common_function2 app_specific_common_function2

    The substitutions will take place transparently on your
    prototypes, declarations, and invocations. The user's
    code that links to this stuff must _not_ #include that
    header file, so it can happily use its _own_ common_function1
    without interacting with your name space.

    I might take it to another level, and

    #define MANGLE(x) GOLDENGATE_ ## x
    #define common_function1 MANGLE(common_function1)
    #define common_function2 MANGLE(common_function2)

    This makes it easier to change your namespace in a hurry.

    You can also play linker tricks, but that's probably harder,
    non-portable, and definitely off topic for c.l.c.

    - Larry
     
    Larry Doolittle, Apr 7, 2004
    #5
  6. Eric

    Eric Guest

    Thanks. I thought of another solution you started to suggest (the
    linker).

    I do have the option of loading a dynamic shared object (this program
    runs under win and unix, many flavors). If I'm the shared object, and
    I have a function with the same name as a "public" in the main, will I
    get a collision? In other words, are the rules same or different than
    with static libs? Seems like this might do it.

    Header suggestion is also good, would go like this?

    /* mangle.h */

    #define common_function MANGLED_FUNCTION_123235

    Only problem with that is looking at a thousand functions across a
    hundred source files.
     
    Eric, Apr 9, 2004
    #6
  7. In article <>, Eric wrote:
    >
    > Header suggestion is also good, would go like this?
    >
    > /* mangle.h */
    >
    > #define common_function MANGLED_FUNCTION_123235


    Roughly, yes. Although I would keep some vestige of the
    common_function name in the mangled version.

    > Only problem with that is looking at a thousand functions across a
    > hundred source files.


    You obviously need some automation. There are better languages
    than C in which to rifle through all those files to come up
    with the contents of mangle.h. If you are masochistic enough
    to try in C, come back to this group with sample code. Otherwise,
    ask a friend fluent in perl or python for help getting started.
    The end result is 100% pure C, though.

    - Larry
     
    Larry Doolittle, Apr 10, 2004
    #7
  8. Eric

    Eric Guest

    Agree with the automation suggestion. To that end, are there any
    utilities you know of that will parse a bunch of C files and:
    1) output all the function names defined in those files;
    2) list which functions are called by other functions and in which
    module (from that, we can derive the "publics")

    Assuming something like that already exists, would be easy to write
    python to mangle the names and come up with a mangle.h.
     
    Eric, Apr 10, 2004
    #8
  9. Eric

    Ed Morton Guest

    Eric wrote:
    > Agree with the automation suggestion. To that end, are there any
    > utilities you know of that will parse a bunch of C files and:
    > 1) output all the function names defined in those files;
    > 2) list which functions are called by other functions and in which
    > module (from that, we can derive the "publics")
    >
    > Assuming something like that already exists, would be easy to write
    > python to mangle the names and come up with a mangle.h.


    Yes. Take a look at "cscope" and it's GUI front-end, "cbrowser" both
    available for free at:

    http://cscope.sourceforge.net/
    http://cbrowser.sourceforge.net/

    Also, check out "ccalls" which is available for a small charge at:

    http://www.bell-labs.com/project/wwexptools/paypackages.html

    Regards,

    Ed.
     
    Ed Morton, Apr 10, 2004
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Murrgon
    Replies:
    3
    Views:
    1,569
    Roedy Green
    Jun 9, 2004
  2. Adam
    Replies:
    29
    Views:
    721
    srepmub
    Apr 3, 2009
  3. Adam
    Replies:
    3
    Views:
    301
    R. David Murray
    Mar 18, 2009
  4. mechtheist
    Replies:
    2
    Views:
    992
  5. Ishmael

    Create zombie intentionally?

    Ishmael, Mar 8, 2007, in forum: Perl Misc
    Replies:
    5
    Views:
    219
    Bart Lateur
    Mar 8, 2007
Loading...

Share This Page