4 ms·
There are lot of "numbers" not actually being numbers. E.g. phone "numbers" are not numbers. The same as a house "numbers" are not numbers. Version "numbers" ar
by foepys 5y ago
There are lot of "numbers" not actually being numbers. E.g. phone "numbers" are not numbers. The same as a house "numbers" are not numbers. Version "numbers" are also often not numbers (e.g. 2.1.230-rc.1).
If the OP bug was really triggered by a string of numerical characters not fitting into a 32bit integer, all the trouble of saving a few bytes on the client system were not worth it.
- petee 5y agoYes, that is what the OP of the thread said, I've read it. Version numbers can be numbers if you want, and plan them to be. Which is the case here, its not a string fit into a 32 bit integer, its actually an integer. But they didn't think to check the max size which would only fit in an unsigned. Its an odd choice on their part, but certainly would have worked.
- foepys 5y agoThis very much depends on the protocol. Microsoft loves XML and and if the update package has an XML manifest with update information attached to it, it's very well a string that gets serialized to a number. The same applies to JSON and other text-based formats.
- petee 5y agoAnd that is fine though because at some lower level everything becomes a number to a computer. I think everyone is getting hung up on this string/number difference; data from humans is going to come as a string, thats no reason to store or process it as such. Plenty of data is stored in varied types for processing that are efficient for a computer, for example DNS has been using date-based serial numbers successfully for decades, and stored internally as uint32.