3 ms·

Hyrum's Law applies: the API of any software component is the entire exposed surface, not just what you've documented. Hence, if you have FILE well-defined some

Hyrum's Law applies: the API of any software component is the entire exposed surface, not just what you've documented. Hence, if you have FILE well-defined somewhere in a programmer-accessible header, somebody somewhere can and will poke at the internal bits in order to achieve some hack or optimization.

krylon 1y ago
OTOH, yes. 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=42163 https://devblogs.microsoft.com/oldnewthing/20031015-00/?p=42...
- brokencode 1y ago
  Yes, it would not be sane to depend on implementation details of something like this. 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.
  - krylon 1y ago
    Such is life, yes.
ars 1y ago
> to achieve some hack or optimization. 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.
- Tractor8626 1y ago
  Typical "early-in-carrier" thinking. Copying implementation is totally correct move here. 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.
  - ars 1y ago
    > Typical "early-in-carrier" thinking. 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.
    - Tractor8626 1y ago
      What I meant are "avoid copy paste at all cost" and "I'm center of the world. What I want is the only thing that matters"-thinking. 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.
- high_na_euv 1y ago
  Access modifiers exist so ppl dont shoot themselves
  - ars 1y ago
    I never asked anyone for such protection, and I don't want it.
    - high_na_euv 1y ago
      Fortunately as time showed such things are over all beneficial for software engineers worldwide You can usually use other langs
crest 1y ago
The OpenBSD answer to this is: fuck them they should've known better. The few pieces of software that do this and have an active port maintainer will get patched. The rest will stay broken until somebody cares to deal with the change.
- zahlman 1y ago
  And for everything that people say about backwards compatibility, and for all the times that something has broken on me... man, I'm still glad that there are people who will stand up and defend that attitude. It isn't breaking things if you point out where they were already broken. And moving fast is defensible when the only alternative is standing still.
- bitwize 1y ago
  One time, when we were discussing a potential internal change that threatened to break ill-behaved software, Steve Summit told a story like this: "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...

krylon 1y ago

OTOH, yes. 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=42163 https://devblogs.microsoft.com/oldnewthing/20031015-00/?p=42...

brokencode 1y ago
Yes, it would not be sane to depend on implementation details of something like this. 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.
- krylon 1y ago
  Such is life, yes.

ars 1y ago

> to achieve some hack or optimization. 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.

Tractor8626 1y ago
Typical "early-in-carrier" thinking. Copying implementation is totally correct move here. 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.
- ars 1y ago
  > Typical "early-in-carrier" thinking. 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.
  - Tractor8626 1y ago
    What I meant are "avoid copy paste at all cost" and "I'm center of the world. What I want is the only thing that matters"-thinking. 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.
high_na_euv 1y ago
Access modifiers exist so ppl dont shoot themselves
- ars 1y ago
  I never asked anyone for such protection, and I don't want it.
  - high_na_euv 1y ago
    Fortunately as time showed such things are over all beneficial for software engineers worldwide You can usually use other langs

crest 1y ago

The OpenBSD answer to this is: fuck them they should've known better. The few pieces of software that do this and have an active port maintainer will get patched. The rest will stay broken until somebody cares to deal with the change.

zahlman 1y ago
And for everything that people say about backwards compatibility, and for all the times that something has broken on me... man, I'm still glad that there are people who will stand up and defend that attitude. It isn't breaking things if you point out where they were already broken. And moving fast is defensible when the only alternative is standing still.
bitwize 1y ago
One time, when we were discussing a potential internal change that threatened to break ill-behaved software, Steve Summit told a story like this: "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...