3 ms·

Anything you do will take 3x the memory, so yes... I cant see why anyone would store as a string internally, you have to decode into a number anyway so just ext

by petee 5y ago

Anything you do will take 3x the memory, so yes... I cant see why anyone would store as a string internally, you have to decode into a number anyway so just extra work. Strings are only useful to humans. Edit: reading all the comments here, I get the feeling high level programmers don't fully understand how things are represented at the low level, there is no purpose in storing a version/serial as a string.

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 ago
  Yes, 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 ago
    This 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 ago
      And 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.
jeroenhd 5y ago
Re your edit: these days, most developers are web developers where people don't care about these optimizations. It's a little silly that a test didn't catch this problem, but using a version number somewhere high up in the long makes total sense to me. After all, version numbers can be anything you define them to be, as long as they're unique. You'd like them to be sortable, but they don't even have to be.
- petee 5y ago
  Sorry, I edited twice (just for confusion hah). I don't think it's that they don't care, I suspect many simply do not understand what is under the hood in the first place; and they don't need to when doing web development. The fact that some here suggest storing version as a string is some how faster and safer is a big give away.
  - jeroenhd 5y ago
    Perhaps saying they don't care is a bit much, they usually just don't need to care. The data is delivered to most websites in the form of JSON which can be parsed to any data format you want, and at that point it might even be faster to do a string compare to skip the double/int conversion.
    - petee 5y ago
      I got what you were saying. That certainly may be case, depending on application. It looks in this case like its just definition files being loaded into memory, and if they need to compare that version more than once, doing it as a single operation binary comparison will be significantly faster than continually comparing a UTF-8 string (SIMD aside)

by petee 5y ago

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 ago
Yes, 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 ago
  This 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 ago
    And 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.

jeroenhd 5y ago

Re your edit: these days, most developers are web developers where people don't care about these optimizations. It's a little silly that a test didn't catch this problem, but using a version number somewhere high up in the long makes total sense to me. After all, version numbers can be anything you define them to be, as long as they're unique. You'd like them to be sortable, but they don't even have to be.

petee 5y ago
Sorry, I edited twice (just for confusion hah). I don't think it's that they don't care, I suspect many simply do not understand what is under the hood in the first place; and they don't need to when doing web development. The fact that some here suggest storing version as a string is some how faster and safer is a big give away.
- jeroenhd 5y ago
  Perhaps saying they don't care is a bit much, they usually just don't need to care. The data is delivered to most websites in the form of JSON which can be parsed to any data format you want, and at that point it might even be faster to do a string compare to skip the double/int conversion.
  - petee 5y ago
    I got what you were saying. That certainly may be case, depending on application. It looks in this case like its just definition files being loaded into memory, and if they need to compare that version more than once, doing it as a single operation binary comparison will be significantly faster than continually comparing a UTF-8 string (SIMD aside)