4 ms·

You're right but thats not the issue here, the version is structured as a number but they failed to give it a type large enough to represent it; simply a signed

by petee 5y ago

You're right but thats not the issue here, the version is structured as a number but they failed to give it a type large enough to represent it; simply a signed/unsigned screwup.

masklinn 5y ago
That's not a fix, barely an improvement, really just a shitty workaround: the exact same issue rear its head again in 2043. The actual fix is exactly what the original comment states: a version is not a number.
- petee 5y ago
  Oh I agree its a bad long term solution, but assuming they had noticed and used the correct type, 2043 is likely well past the lifetime of the product and would have worked fine till then. Not great, but certainly passable.
  - masklinn 5y ago
    > Oh I agree its a bad long term solution, but assuming they had noticed and used the correct type, 2043 is likely well past the lifetime of the product You expect Microsoft Exchange to stop being used some time in the next 20 years?
    - petee 5y ago
      That version yes, absolutely. I expect at some point Microsoft will have made enough updates that they will say X version is no longer supported, and it will stop working on its own. And its not like it's a product installed on some embedded device that will never get updates until then, Exchange will get security fixes for as long as it is exists and nobody will be running this version in 20 years. Even more likely, we'll have new protocols the current version doesn't support, so the bug will have been long fixed or noticed.
      - masklinn 5y ago
        > That version yes, absolutely. But in your alternate timeline the issue would only have been hit in 2043, and since in our timeline it was not noticed before it was hit, there is no reason to believe it would have been noticed in the alternate. So the exact same issue would have occurred, a few years later. I fail to see why that would be an improvement. > Even more likely, we'll have new protocols the current version doesn't support, so the bug will have been long fixed or noticed. That is a completely unsubstantiated assertion.
        petee 5y ago
        I'll quote myself again, "Oh I agree its a bad long term solution, but assuming they had noticed and used the correct type, 2043 is likely well past the lifetime of the product and would have worked fine till then" I never suggested it was any improvement except for the advantage of time; although I shouldn't have used the word 'correct'. Signed 32-bit dates have a well known limitation that people will likely hunt and fix over the next 20 years. But yes, its all unsubstantiated, no doubt there. The real main point of my post you first replied to is that it doesn't matter that the version was stored as an integer. The failure happened when they used their own format and didn't confirm it was properly bounded. Everyone here is having a hard time grasping how their data is stored and processed at the low level - your 'string' is still just an array of 8-bit bytes. Storing an only-increasing number as any form of integer is a perfectly acceptable, and efficient way for a computer to compare and process. Version numbers are one of those. Phone numbers are obviously not.
lolinder 5y ago
The version is not structured as a number, it's structured as a string of digits that incidentally resembles a number. There are no operations that take two version numbers and return a new version number, so they are not numbers.
- petee 5y ago
  That is how they are entered by a human, yes. Then they are converted to binary and processed, like everything else. There is no need to add two version numbers together, but as they only ever increasing, its sane and efficient to store, and compare binary. Everything in software takes data in one form and processes it into another. There are no 'strings', there are no version numbers. There is only binary. They simply did not give enough space to store it, thats all. DNS is a perfect example, which stores serial numbers internally as an unsigned 32 and has worked for decades and will continue to. But they chose the format of YYYYMMDDnn which will last far longer than a 2 digit year.

by petee 5y ago

You're right but thats not the issue here, the version is structured as a number but they failed to give it a type large enough to represent it; simply a signed/unsigned screwup.

masklinn 5y ago

That's not a fix, barely an improvement, really just a shitty workaround: the exact same issue rear its head again in 2043. The actual fix is exactly what the original comment states: a version is not a number.

petee 5y ago
Oh I agree its a bad long term solution, but assuming they had noticed and used the correct type, 2043 is likely well past the lifetime of the product and would have worked fine till then. Not great, but certainly passable.
- masklinn 5y ago
  > Oh I agree its a bad long term solution, but assuming they had noticed and used the correct type, 2043 is likely well past the lifetime of the product You expect Microsoft Exchange to stop being used some time in the next 20 years?
  - petee 5y ago
    That version yes, absolutely. I expect at some point Microsoft will have made enough updates that they will say X version is no longer supported, and it will stop working on its own. And its not like it's a product installed on some embedded device that will never get updates until then, Exchange will get security fixes for as long as it is exists and nobody will be running this version in 20 years. Even more likely, we'll have new protocols the current version doesn't support, so the bug will have been long fixed or noticed.
    - masklinn 5y ago
      > That version yes, absolutely. But in your alternate timeline the issue would only have been hit in 2043, and since in our timeline it was not noticed before it was hit, there is no reason to believe it would have been noticed in the alternate. So the exact same issue would have occurred, a few years later. I fail to see why that would be an improvement. > Even more likely, we'll have new protocols the current version doesn't support, so the bug will have been long fixed or noticed. That is a completely unsubstantiated assertion.
      - petee 5y ago
        I'll quote myself again, "Oh I agree its a bad long term solution, but assuming they had noticed and used the correct type, 2043 is likely well past the lifetime of the product and would have worked fine till then" I never suggested it was any improvement except for the advantage of time; although I shouldn't have used the word 'correct'. Signed 32-bit dates have a well known limitation that people will likely hunt and fix over the next 20 years. But yes, its all unsubstantiated, no doubt there. The real main point of my post you first replied to is that it doesn't matter that the version was stored as an integer. The failure happened when they used their own format and didn't confirm it was properly bounded. Everyone here is having a hard time grasping how their data is stored and processed at the low level - your 'string' is still just an array of 8-bit bytes. Storing an only-increasing number as any form of integer is a perfectly acceptable, and efficient way for a computer to compare and process. Version numbers are one of those. Phone numbers are obviously not.

lolinder 5y ago

The version is not structured as a number, it's structured as a string of digits that incidentally resembles a number. There are no operations that take two version numbers and return a new version number, so they are not numbers.

petee 5y ago
That is how they are entered by a human, yes. Then they are converted to binary and processed, like everything else. There is no need to add two version numbers together, but as they only ever increasing, its sane and efficient to store, and compare binary. Everything in software takes data in one form and processes it into another. There are no 'strings', there are no version numbers. There is only binary. They simply did not give enough space to store it, thats all. DNS is a perfect example, which stores serial numbers internally as an unsigned 32 and has worked for decades and will continue to. But they chose the format of YYYYMMDDnn which will last far longer than a 2 digit year.