Does source incompatibility always imply binary incompatibility?

Question

Any examples demonstrating where source compatibility is broken yet binary compatibility is maintained is welcome.

Answer 1

Yes, source incompatibility implies binary incompatibility. If the signatures have changed in the source code, the signatures will change in the resulting binary and, hence, the resulting binaries will be incompatible.

Answer 2

Different versions of static-linked libraries on various machines might result in a binary compiled on machine A working properly on machine B but attempts to compile it from source on machine B failing. But aside from that, source incompatibility generally implies binary incompatibility.

Answer 3

Imagine the type of a function parameter changes without the actual size or underlying type changing (say, from one enum to another or from long to int). That'll break source code because of the type check but may not affect the binary compatibility. (Depends on the exact environment -- .NET will be annoyed, but C/C++ won't.)

Answer 4

Old version:

struct inner {
  int bar;
}

struct foo {
  struct inner i;
};

void quux(struct foo *p);

New version:

struct inner2 {
  int bar;
};

struct foo {
  struct inner2 i;
};

void quux(struct foo *p);

Broken code:

struct foo x;
struct inner *i = &x.i;
i->bar = 42;
quux(&x);

Since the only difference is the name of the struct, and the inner struct's type name is erased during compilation, there's no binary incompatibility.