name conflicts in C

The company I work for hired/cooperated with two other companies on some code for an embedded system. One company coded the operating system, and the other coded a driver that is used by the operating system. Due to FAA requirements, the code must be in C - no features from C++ are allowed. It is now our task to get the driver integrated with the operating system and get applications running on all of it. I don't know what kind of programmers the other companies employed, though - there are functions, structures, and global variables with single character names. Among other name conflicts, the operating system defines a function s(), and the driver has a structure s. These two things appear in thousands of lines of code, and it must all be compiled together to work. They are never both used in the same file, however. Is there some incredibly clever way of avoiding this conflict without spending what could literally be days inserting descriptive variable names in place of 's' and the like? In C++, I'd rely on some combination of namespaces and function overloading to make up for others bad coding practices, but I don't have that liberty this time.

edit:: Prelude's post is more helpful..

Bwahahahahahahaha! It totally sucks to be you right now! :D

>Is there some incredibly clever way of avoiding this conflict
No, not really. Your best bet is scripting up a quick filter that parses the code to differentiate between the driver code and the system code, then renames the driver identifiers that are causing a conflict. Depending on how many conflicts there are, this could be only a handful of ad hoc programs in, say, Perl. Then, of course, you have to verify that the script made all of the right changes, but that's considerably less error prone than trying to manually change names in thousands of lines of code.

> The company I work for hired/cooperated with two other companies on some code for an embedded system
What were the contract terms for engaging these other two companies for this work. I'd imagine that it would be something pretty rigorous if as you say the whole thing is supposed to be FAA certified, though I wouldn't be surprised if it wasn't.

For example, check whether you can just bounce the problem back to the subcontractors saying they don't compile together and get them to sort out their own mess.

Also consider that whilst renaming is possible (if you have the source), that you completely mess up any possibility of ongoing support (the software you have is now different to your contractors software). If by some chance they're providing any kind of warranty or support, renaming anything might void your support.
Do you even have a configuration management system like RCS or CVS or ... to help manage such a problem?

For the future - make sure that the next time you subcontract a piece of work that you specify a namespace for each of your subcontractors.

Suggestions for coal-face joe who's got to sort out the whole sorry mess.
If your linker is GNU-ld, then you might be able to use things like
--retain-symbols-file FILENAME
--wrap SYMBOL
to incrementally link both subsystems in such a way that all the problem symbols are effectively hidden from each other.

I don't know what the contract terms were; the way things work around this place is that source code arrives from on high, and we are told to put it all together and make it work, and the expectation is always that we will have it done yesterday (or last week, if it's a rush). Often, we don't even have the code or specs we need until after the deadline is passed. The situtation is further complicated by the fact that the two companies that wrote this code were contracted not just by our company - they're providing the same product for approximately 100 other companies, but my company takes the rap whenever something goes wrong. (If that sounds like a crap deal, it is, and we're doing it completely free for a couple years - but it turns into a cash cow for 70 years after that with no further work on our part).

As far as CVS goes ... I wish. It's an engineering company, and doesn't see the need for computer science people to write good code and implement ideas like that. There are hundreds of electrical engineers writing code around this place, and I only know of a single software engineer employed by the company. I do not understand it, other than that the electrical engineers will be more "reusable" for other projects that are perhaps not programming intensive and involve more circuitry. Meanwhile, though, source code gets placed in random spots on a network share, and to find it requires searching through terabytes of data. It's a mess.

I'll look into those linker options - they sound promising.

Sounds to me like you need to find a better company to work for :rolleyes:

Quote:

---

Originally Posted by Prelude

No, not really. Your best bet is scripting up a quick filter that parses the code to differentiate between the driver code and the system code, then renames the driver identifiers that are causing a conflict. Depending on how many conflicts there are, this could be only a handful of ad hoc programs in, say, Perl. Then, of course, you have to verify that the script made all of the right changes, but that's considerably less error prone than trying to manually change names in thousands of lines of code.

---

This can be done with a powerfull text editor/or simple code editor like Ultra edit. Replace in files-> match case, match full word, ... easy ! :cool: Then some manual tweaks to conflicts that might appear.

>Replace in files-> match case, match full word, ... easy !
Okay. How does that solution work with this?

Code:

---

double s ( int i ) {}
void s ( void ) {}

int main ( void )
{
  double d = s ( 10 );

  /* ... */

  s();
}

---

If you match case, match full word for "s", and replace in files with "q", that gives you this:

Code:

---

double q ( int i ) {}
void q ( void ) {}

int main ( void )
{
  double d = q ( 10 );

  /* ... */

  q();
}

---

Not much better, is it? Some form of parsing would be needed to determine which s to change to q and which s to leave alone. I don't know of a text editor that would make such a replacement as easy as you suggest.

Quote:

---

Okay. How does that solution work with this?

Code:

---

double s ( int i ) {}
void s ( void ) {}

---

---

It'd work better than your attempt at compiling this. This is C after all, where there is no such thing as function overloading. ;)


Quzah.

Quote:

---

Originally Posted by quzah

It'd work better than your attempt at compiling this. This is C after all, where there is no such thing as function overloading. ;)


Quzah.

---

Aye, but if it compiled, there'd be no problem at all.

Ermm...they should use namespaces...and not give functions such stupid names.

>It'd work better than your attempt at compiling this.
Congratulations, quzah, you completely missed the point. I know it doesn't compile because of a name conflict. That's the entire point of this thread. :rolleyes:

>Ermm...they should use namespaces
They probably would if it were in C++. But C doesn't have namespaces. At least not the kind that you're thinking of.

I doubt in their code they have two functions in the same file called the same exact thing. So no, I didn't miss the point.

Oh wait, I'm right:

Quote:

---

Originally Posted by confuted

They are never both used in the same file, however.

---

A search and replace should be just fine. Why you ask? Well because of the above statement.

Search:
"double s", "double sfromOS"
"int s", "int "sfromlocal"

Then, you don't hit the "Yes, replace all instances.", you simply hit "skip" when it comes around to a case that doesn't have it, and hit "replace" when it's the right thing. I mean sure, it takes a few brain cells for you to actually think if this is the right thing to replace or not, but I like to think I have a few.

If you don't like that, try these fun variants:
" s", " sfromOS"
" s(", "sfromOS"

Etc etc etc. But I suppose you could write your own C parser if you like. :rolleyes:


Quzah.