Hacker News Search

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)

pigbearpig 5y ago

These should have been strings, end of story. You can sort a string. Amazing to see storing a non-number as as number being defended. Truly CS101.

petee 5y ago
I'm curious which languages you learned in CS101 (actual question, not snark) Every non-number, as you put it, is just a number to a computer. Comparing binary is faster than sorting strings, and it makes zero sense to waste memory simply so a human could potentially read it.
- jraph 5y ago
  But versions are for human beings. Otherwise, a timestamp, a date, a commit hash or an increment would do.
  - petee 5y ago
    That's not true, they can be for either humans, computers, or both. Software still has to understand and do something with that version number, even if it came from a human. And if it has to store, sort, or process that number a lot, it will still be faster to store and compare binary than a string. For comparison, I think some here would be shocked to learn their IPv4 address is stored as an unsigned 32-bit integer. Its not a number, and definitely not faster to use as a string.
DSMan195276 5y ago
You can certainly sort a string, but I think there are valid reasons to avoid it if possible. What they shouldn't be doing is trying to shove it into a single 32-bit integer - if they parsed it into separate integers for each of the individual parts (like a simple date representation would do) then the issue would go away. Whether it's worth that extra work to avoid the string comparison is debatable, but if they go on to mask out parts of the version number and look at them individually (Ex. Only the year, or only the revision number) than it would probably be worth it to just do all the parsing upfront and avoid any messing with strings after that.
srj 5y ago
I guess it depends on the language but using a string for this doesn't seem like a great choice except for user display / logging. Given this is a version number you'd want to support comparison operators, and a struct with those operators defined (and a string format method) would make more sense imo.
mr_toad 5y ago
Depends on the language and function. Some sorting algorithms happily rank ‘9’ > ‘10’.