ソースの非互換性は、常にバイナリの非互換性を意味しますか？

Question

ソースの互換性が壊れているが、バイナリ互換性が維持されていることを示す例は歓迎です。

Answer 1

旧バージョン - （.NETが迷惑になりますが、C/C++しません正確な環境により異なります。）

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

唯一の違いは、構造体の名前であり、そして内側の構造体の型の名前はコンパイル時に消去され、何のbがありませんので、 inary incompatibility。

Answer 2

さまざまなマシン上の静的リンクされたライブラリのバージョンが異なると、マシンAでコンパイルされたバイナリがマシンBで正常に動作することがありますが、マシンBのソースからコンパイルできません。しかし、ソースの非互換性は、一般的にバイナリの非互換性を意味します。

Answer 3

関数のパラメータの型が実際のサイズや基底型が変更されていないとします（たとえば、ある列挙型から別の型へ、またはlongからintへ）。型チェックのためにソースコードが壊れてしまいますが、バイナリ互換性には影響しません。

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); 

ブロークン・コード：