Всегда ли несовместимость источника подразумевает двоичную несовместимость?

Question

Любые примеры, демонстрирующие, где совместимость с исходным кодом нарушена, но поддерживается двоичная совместимость, приветствуются.

Answer 1

Старая версия:

struct inner {
  int bar;
}

struct foo {
  struct inner i;
};

void quux(struct foo *p);

Новая версия:

struct inner2 {
  int bar;
};

struct foo {
  struct inner2 i;
};

void quux(struct foo *p);

Сломанный код:

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

Поскольку единственным отличием является имя структуры, а имя типа внутренней структуры стирается во время компиляции, двоичная несовместимость отсутствует.

Answer 2

Представьте, что тип параметра функции изменяется без изменения фактического размера или базового типа (скажем, с одного перечисления на другое или с long на int). Это нарушит исходный код из-за проверки типа, но может не повлиять на двоичную совместимость. (Зависит от конкретной среды - .NET будет раздражен, а C/C++ - нет.)

Answer 3

Различные версии статически связанных библиотек на разных машинах могут привести к тому, что двоичный файл, скомпилированный на машине A, будет работать правильно на машине B, но попытка скомпилировать его из источника на машине B не удастся. Но кроме этого, несовместимость источника обычно подразумевает двоичную несовместимость.