OTOH, when coding, I consider FILE to be effectively opaque in the sense that it probably is not portable, and that the implementers might change it at any time.
I am reminded of this fine article by Raymond Chen, which covers a similar situation on Windows way back when: https://devblogs.microsoft.com/oldnewthing/20031015-00/?p=42...
But the sad reality is that many developers (myself included earlier in my career) will do insane things to fix a critical bug or performance problem when faced with a tight deadline.
"Once upon a time, pointers on the Macintosh had 24 bits. The upper 8 bits were reserved for flags. Apple warned developers not to look directly at the flags in the upper 8 bits, but to use the macros that were supplied as part of the API -- but third-party developers looked directly at the upper 8 bits anyway. When System 7 came out with full 32-bit pointers, a lot of old applications broke because of this!"
Of course, what he didn't mention at the time was that System 7 provided a toggle that allowed these programs to run with old-school 24-bit pointers -- the equivalent concession is something I don't think OpenBSD is willing to make.
Nevertheless, vendors can and have broken full backward compatibility in cases where the developers "should've known better". Hyrum's Law just states that there will be a few that don't get the message and will watch their software break when these changes are made...
Or functionality. Happens to me all the time I have some Java class that's marked Final, so instead of just extending the class and moving on, I have to copy/paste the entire class wholesale to accomplish my goal.
Personally I hate "nanny" languages that block you from accessing things. It's my computer, and my code, and my compiler. Please don't do things "for my own good", I can decide that for myself.
(And yes, I am aware of the argument that this lets the original programmer change the internals, in practice it's not such a big problem. Or the cure is worse than the problem - for example my copy/paste example.)
Another example is a private constant. Instead of allowing me to reference it, I have to copy it. How is that any better? If the programmer has to change how the constant works then they can do so, and at that point my code will break and I'll .... copy the constant. But until then I can just use the constant.
All projects mentioned should have forked stdio and added their hacks/optimisations/functionality to that.
They were just too lazy. Can't blame them though. Writing C code is torture after all. One should cut all the corners they could.
Other way around. When I first started I thought these access restrictions were a great idea. Make sure, I, and other, only program "correctly".
When I got more mature I found how often they are impediments, and how little they actually help.
I don't want someone else protecting me from myself. I just don't want that, no matter how well intentioned.
About access restrictions. We have two nice examples here
1. Stdio devs can't freely make modifications because someone's code depends on private implementation details
2. And yours example. You tried to do wrong thing and those access restriction made you suffer and do the right thing.
Works as intended I'd say.
You can usually use other langs