internal/external linkage

I was wandering why this works:

file1.cpp

Code:

---

#include <iostream>

struct Point {
      int a, b;
};

void f(Point *);

int main(int argc, char *argv[])
{
      Point a;
      f(&a);
      return 0;
}

---

file2.cpp

Code:

---

struct Point {
      int a, b, c;
      float z;
};

void f(Point *p)
{
    p->a = 5;
    p->b = 5;
    p->c = 7;
    p->z = 25.5;
}

---

What will happen here?

My compiler doesn't really detects anything.

Edit: the program crashes when i try changing value of z there.

Does this means the programmer has to take care of inconsistent type declarations throughout several files?

Point a (from file1) is in stack storage. function f() will write beyond the proper limit of file1's Point a. In this case, probably no big deal (although a gross error), since there is nothing else (obvious) in the stack that is used by main.

For pretty much the same reason that

Code:

---

char c;
strcpy( &c, "oops" );

---

Beyond being syntactically valid, there is only a finite amount of checking that the compiler can do from inspecting a single source file. Code checking tools like lint, which check ALL the code would most likely spot the anomaly. But even with these, it's not that hard to create something which passes every analysis tool, but the result simply doesn't work.


> since there is nothing else (obvious) in the stack that is used by main.
You mean like the return address back to the calling environment?

So, a good thing to do would be to include type definitions into a .h file and then just include the .h file in the files which depend on those types?

Quote:

---

Originally Posted by Salem

> since there is nothing else (obvious) in the stack that is used by main.
You mean like the return address back to the calling environment?

---

ha ha ha. ho ho ho. I figured there were other things out there, but I have never studied stack structure and layout (thus my clever use of "obvious")

Quote:

---

Originally Posted by Tool

So, a good thing to do would be to include type definitions into a .h file and then just include the .h file in the files which depend on those types?

---

Yes. Excellent idea.

Quote:

---

Originally Posted by Salem

Beyond being syntactically valid, there is only a finite amount of checking that the compiler can do from inspecting a single source file. Code checking tools like lint, which check ALL the code would most likely spot the anomaly. But even with these, it's not that hard to create something which passes every analysis tool, but the result simply doesn't work.

---

It would take quite a bit of analysis to prove that this code is wrong (and it might not even be wrong). Simply having two types with the same name is not necessarily an error -- in fact, it definitely does happen and is why namespaces were invented. The lint tool would have to be smart enough to see that an instance of one type is being treated as an instance of another by analyzing data flows and function calls. And even if it could see that, it still might be intentional (though probably a bad idea).

This type of thing could be caught at compile time if aggregate type names had signatures applied to them the way that function names do. But that's probably a pipe dream.