utility to intentionally mangle function names?

[Eric]

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?

[Alan Balmer]

On 7 Apr 2004 07:41:45 -0700, ef***@goldengate.com (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
re************************@att.net

[Eric Sosman]

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.

--
Er*********@sun.com

[Dan Pop]

In <b7**************************@posting.google.com > ef***@goldengate.com (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: Da*****@ifh.de

[Larry Doolittle]

In article <c5**********@sunnews.cern.ch>, Dan Pop wrote:

In <b7**************************@posting.google.com > ef***@goldengate.com (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

[Eric]

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.

[Larry Doolittle]

In article <b7**************************@posting.google.com >, 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

[Eric]

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.

[Ed Morton]

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/wwe...ypackages.html

Regards,

Ed.