JdeBP<p><span class="h-card" translate="no"><a href="https://infosec.exchange/@david_chisnall" class="u-url mention" rel="nofollow noopener" target="_blank">@<span>david_chisnall</span></a></span> </p><p>You've built a argument on the assumption of binary incompatibility, but in fact there was none.</p><p>There was no layout change nor symbol name changes.</p><p>The struct layout stayed entirely the same. The struct definition merely moved from one header to another and replaced the declarations of some members with external library types rather than their underscored aliases that standard headers use.</p><p>The thing that would have introduced binary incompatibility, which <a href="https://mastodonapp.uk/tags/OpenBSD" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>OpenBSD</span></a> has had to deal with this year, <a href="https://mastodonapp.uk/tags/FreeBSD" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>FreeBSD</span></a> had already done 7 years earlier back in 2001, and is still the case now.</p><p>By 2008, it was just moving struct definitions out of a standard header and removing "inline" macros. The one thing in base that that broke in 2008 (because of *source* incompatibility) went away in 2011, and Jordan Hubbard patched some stuff in ports a decade ago.</p><p>It is entirely feasible in 2025 for FreeBSD to regain parity with OpenBSD quite simply.</p><p><a href="https://mastodonapp.uk/tags/stdio" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>stdio</span></a> <a href="https://mastodonapp.uk/tags/StandardC" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>StandardC</span></a> <a href="https://mastodonapp.uk/tags/OpaqueTypes" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>OpaqueTypes</span></a></p>