2 ms·

changing typedef time_t int32_t to typedef time_t int64_t does not change your api openbsd tends to be respectful to the api however the binary interface

by somat 4y ago

changing typedef time_t int32_t to typedef time_t int64_t does not change your api openbsd tends to be respectful to the api however the binary interface changes every couple of weeks. and they have a flag day(breaking incompatible change) every year or so. As such, actions that are unthinkable on linux, like an abi flag day. The openbsd project has gotten really good at handling, after all, if you break stuff all the time you get good at picking up the pieces. to misquote Raul Julia "For you, linux, the day your abi changed was the most important day of your life. But for me, it was Tuesday." This means that the openbsd project is exceptionally unfriendly to binary only programs(commercial software), As much as I like openbsd I would not even try.

throwawaylinux 4y ago
> changing > > typedef time_t int32_t > > to > > typedef time_t int64_t > > does not change your api Not sure I agree, because time_t itself is part of the API, and programs can use it for more than just calling your syscall, like in their own structures. Linux has found they don't need these flag days, they're an ugly old sledgehammer that used to be quite common in systems programming, but Linux (and presumably Windows though I haven't seen the source code to make a judgement) really pioneered much more disciplined, thoughtful, and structured way to manage API and ABIs such that new versions can be brought in with little disruption and old versions can also be maintained usually with little burden to the code base. It's a better system all around IMO, even if you did decide to remove the old stuff right afterwards, the change process is just the right way to go. And keeping around the old stuff and not having to change the world or break your users is actually a good thing too, the ability to make changes less painful than these big hammer flag days makes things very flexible and adaptable.

by somat 4y ago

throwawaylinux 4y ago

> changing > > typedef time_t int32_t > > to > > typedef time_t int64_t > > does not change your api Not sure I agree, because time_t itself is part of the API, and programs can use it for more than just calling your syscall, like in their own structures. Linux has found they don't need these flag days, they're an ugly old sledgehammer that used to be quite common in systems programming, but Linux (and presumably Windows though I haven't seen the source code to make a judgement) really pioneered much more disciplined, thoughtful, and structured way to manage API and ABIs such that new versions can be brought in with little disruption and old versions can also be maintained usually with little burden to the code base. It's a better system all around IMO, even if you did decide to remove the old stuff right afterwards, the change process is just the right way to go. And keeping around the old stuff and not having to change the world or break your users is actually a good thing too, the ability to make changes less painful than these big hammer flag days makes things very flexible and adaptable.