OpenBSD在-current版本中将stdio(3)的FILE类型底层结构改为不透明，并全面更新了相关库的版本号，涉及多个库和头文件的修改。

标题：stdio(3) 变更：FILE 类型现已不透明

在 OpenBSD 的 -current 版本中，stdio(3) 的 FILE 类型的底层结构体已被改为不透明（opaque），并全面提升了相关库的版本号。这一变更由 yasuoka 在 2025 年 7 月 16 日提交，涉及多个库和文件的修改，包括 libc、libcrypto、libcurses 等。

具体来说，__sFILE 的定义被移到了 libc/hidden/_stdio.h 中，这意味着所有直接引用 FILE 对象内部结构的程序将无法编译。虽然 stdin、stdout 和 stderr 不再引用 __sF[]，但为了过渡的顺利进行，暂时保留了 __sF、__srget 和 __swbuf 符号，这些符号将在未来被删除。

此次变更影响广泛，涉及多个系统组件，包括 libcrypto、libtls、libssl 以及之前提到的性能分析子系统。对于通常从源代码构建系统的用户，强烈建议使用快照升级来应对这些变更。

这一重大调整标志着 OpenBSD 在系统库设计上的进一步优化，尽管短期内可能会带来一些兼容性问题，但从长远来看，这将有助于提高系统的稳定性和安全性。

评论主要围绕FILE结构体的透明性与不透明性展开，涉及不同操作系统的处理方式及其影响。以下是主要观点总结：

1. 对FILE透明性的质疑：

   • 有人认为依赖FILE的内部结构是不良实践。如评论2指出：“However, who should really rely on internals of FILE? Isn't this a bad practice?”（然而，谁应该真正依赖FILE的内部结构？这不是一种不良实践吗？）
   • 评论6提到，非透明的FILE允许与将FILE放入结构体的代码兼容，因为不透明的FILE没有固定大小：“non-opaque FILE also allows for compatibility with code which puts FILE into a structure, since an opaque FILE doesn't have a size.”（非透明的FILE也允许与将FILE放入结构体的代码兼容，因为不透明的FILE没有固定大小。）

2. 不同操作系统的ABI处理方式：

   • 评论3对比了Linux和OpenBSD在ABI变更上的差异，认为Linux在处理ABI变更时效率低下，而OpenBSD则更为灵活：“OpenBSD to Linux: 'For you the day you changed your ABI was the most important day in your life, but for me? It was Tuesday'”（OpenBSD对Linux说：“对你来说，改变ABI的那天是你生命中最重要的一天，但对我来说？那只是星期二。”）
   • 评论5认为BSD系统不惧怕改变，而Linux和Windows则因担心破坏现有代码而陷入困境：“Linux should take note. So much of Windows' headaches stem from not wanting to break things, and needing to support old client code.”（Linux应该注意。Windows的许多问题源于不愿意破坏现有代码，并且需要支持旧的客户端代码。）

3. FreeBSD的尝试与失败：

   • 评论4提到FreeBSD曾尝试将FILE变为不透明，但最终被撤销：“I think FreeBSD tried to opaque FILE, but it was reverted and still non-opaque in main.”（我认为FreeBSD曾尝试将FILE变为不透明，但最终被撤销，主分支中仍然是非透明的。）

4. 对变更动机的疑问：

   • 评论9和10指出，变更的动机未在提交信息和公告文章中明确说明，引发了对其实践的担忧：“So many words in the commit message and the announcement article, yet not a single mention of the rationale?”（提交信息和公告文章中说了这么多，却没有提到任何理由？）
   • 评论10进一步询问变更的原因：“Does anyone know why this change was done? Security reasons? Preparing for future changes?”（有人知道为什么做出这个变更吗？是出于安全原因，还是为未来的变化做准备？）

总结：评论中对FILE结构体的透明性、不同操作系统的ABI处理方式、FreeBSD的尝试以及变更动机提出了质疑和讨论，反映了开发者对系统兼容性和变更透明性的关注。