前段时间I had asked将字段添加到共享库的 struct 是否需要根据语义版本控制对版本字符串进行主要或次要更改。少数参与者倾向于建议进行重大更改。
几个月过去了，我还没有向我的 struct 添加任何字段。但现在可能是时候这样做了。
然而，与此同时，我也一直在考虑这会如何破坏与使用我的库的早期版本编译的程序的二进制兼容性，老实说，就我所想的而言，我还没有发现二进制兼容性的任何可能情况休息。
新字段被添加到结构的末尾，使用我的库的人通常不会自己分配这个struct，而是接收一个指向它的指针作为回调的参数功能。这是我的库用它做的所有事情，用户永远不需要使用这个 struct 调用库。
当旧程序与新版本库一起运行时，可能的情况有两种:
- 在正常情况下(即，旧程序收到一个指向此
struct的指针并读取它需要的字段)，我的库将从现在开始发送一个指向更大的struct< 的指针，但旧程序不知道也不关心。 - 如果旧程序出于某些未知原因分配了这个
struct，它仍然会分配一个较小的结构(程序在编译时确实知道这一点)，但是我的库不知道也不关心，因为它永远不需要从用户那里接收这个struct，它只把它作为一个指针发送。
在之前的讨论中，有人还发布了来自 Linux Program Library HOWTO — §3.6. Incompatible Libraries 的引文:
When a new version of a library is binary-incompatible with the old one the soname needs to change. In C, there are four basic reasons that a library would cease to be binary compatible:
The behavior of a function changes so that it no longer meets its original specification,
Exported data items change (exception: adding optional items to the ends of structures is okay, as long as those structures are only allocated within the library).
An exported function is removed.
The interface of an exported function changes.
案件编号2似乎在谈论不透明结构。我的 struct 不是不透明的，但情况非常相似。但真正的问题是，正如我所说，我还没有找到一个单一的场景，在此更改后二进制兼容性将被破坏。
所以问题还是一样:这是次要版本更改还是主要版本更改？
最佳答案
我能看到的唯一问题是，如果用户执行的操作依赖于您的结构的大小，然后在未更新代码的情况下重新编译程序时会出现意外结果。最有可能受到影响的是 Gentoo 或 Yocto 构建链等非二进制发行版。
例如，如果用户要将这些结构数组的内容写入一个文件，它希望在下次程序运行时读取该文件。如果程序针对新版本的库重新编译，如果它不知道版本之间的变化，就会出现问题。如果存在不使用 sizeof 等不良做法，则可能会出现另一个问题。
关于c - 语义版本控制 : minor or major change?(第二部分)，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/58031508/