c - 语义版本控制：小改动还是大改动？（第二部分）

Question

前段时间我问struct过，根据语义版本控制向共享库添加字段是否需要对版本字符串进行重大或次要更改。少数参与者倾向于提出重大改变。

几个月过去了，我还没有添加任何字段struct。但现在可能是做这件事的正确时机。

然而，与此同时，我也一直在考虑这会如何破坏与使用我的库的先前版本编译的程序的二进制兼容性，老实说，正如我所想的那样，我还没有发现任何可能的二进制兼容性中断的情况。

新字段被添加到结构的末尾，使用我的库的人通常不会struct自己分配这个，而是接收指向它的指针作为回调函数的参数。这就是我的图书馆所做的一切，用户永远不需要使用 this 回调图书馆struct。

当旧程序与新版本的库一起运行时，可能的情况有两种：

1. 在正常情况下（即旧程序收到指向 this 的指针struct并读取它需要的字段），我的库将从现在开始发送指向更大的指针struct，但旧程序不知道它并且不在乎。
2. 如果旧程序出于某些未知原因struct为其自己分配了这个，它仍然会分配一个较小的结构（这是程序在编译时确实知道的），但我的库不知道它也不在乎，因为它永远不需要从用户那里接收这个struct，它只将它作为一个指针发送。

在之前的讨论中，有人还发布了来自Linux Program Library HOWTO — §3.6 的引用。不兼容的库：

当新版本的库与旧版本二进制不兼容时，soname 需要更改。在 C 语言中，库不再兼容二进制有四个基本原因：

1. 函数的行为发生变化，使其不再符合其原始规范，

2. 导出的数据项更改（例外：在结构的末尾添加可选项是可以的，只要这些结构仅在库中分配）。

3. 删除了导出的函数。

4. 导出函数的接口发生变化。

案号 2 似乎在谈论不透明的结构。我struct的不是不透明，但情况非常相似。但真正的问题是，正如我所说，我还没有找到一个单一的场景，在这种变化之后二进制兼容性会被破坏。

所以问题还是一样：这是次要版本还是主要版本更改？

标签： cstructshared-librariesversioningsemantic-versioning

Answer 1

我能看到的唯一问题是，如果用户做了一些依赖于结构大小的事情，然后在没有更新代码的情况下重新编译程序时会出现意外结果。最有可能受到影响的是像 Gentoo 这样的非二进制发行版，或者可能是 Yocto 构建链。

例如，如果用户要将这些结构的数组的内容写入文件，它希望在程序下次运行时读取该文件。如果程序根据库的新版本重新编译，如果它不知道版本之间的变化，就会出现问题。如果存在诸如不使用之类的不良做法，则可能会出现另一个问题sizeof。