4 ms·
Is there a lot of pressure to keep these version number types as compact as possible? I suppose it has to do with the use a tuple of 3 values and a desire to p
by sgtnoodle 6y ago
Is there a lot of pressure to keep these version number types as compact as possible?
I suppose it has to do with the use a tuple of 3 values and a desire to pack them efficiently into an API?
An API for fetching a version number doesn't need to be particularly efficient though. It needs to be friendly to humans and easy to reason about in code.
- hinkley 6y agoHumans can make errors in judgement or execution. When we look at affordances we look at filtering information to influence outcomes, and we try to eliminate mechanical errors like hitting the wrong button or transposing two activities. Which is a long way of saying long numbers get more typos. It’s all a tradeoff though. You just have to have all the competing concerns if you want to get a good answer.
- sgtnoodle 6y agoThat's fine and I generally agree with you, but "humans are bad at big numbers" doesn't seem like a good rationale for choosing a data type for a computer to use to represent a piece of information as part of an API that isn't allowed to change. Computers are fine with arbitrarily large numbers, and in particular, Linux capable platforms are absolutely great at 32 or 64 bit numbers depending on their architecture. Using 8 bit integers seems like it could have been premature optimization. If the original API had just used "int" without thinking about it too much, it would have had the same practical performance as using an 8-bit type, and would have worked up to at least 2 billion on any reasonable platform. Maybe the API needed a guaranteed fixed size across platforms, though, and the original designer thought more than 255 minor versions was crazy? Solving the "large version numbers are bad for this project" problem is a human policy concern, and probably better done via education/documentation or an explicit warning in code (like a compiler warning or console message if the version number is more than 3 base-10 digits.)
- josephg 6y agoI’m not familiar with the code. But my assumption is that it’s not that they chose to use an 8 bit integer for the y-version field. It’s that they chose to use a 24-bit number for the whole version. OxXXYYZZ - Eg 0x050801 for kernel version 5.8.1. That lets you compare kernel version A with kernel version B using a simple u32 cmp. They could have used 16 bits per version field - but that would have needed a 64 bit integer, which is much slower on some of the systems Linux used to run on back when that decision was made. In retrospect that was a bad choice, but I’m sure it seemed fine in the 90s. The problem is that if they spill the minor version to 16 bits (xxyyyyzz) then kernel version 4.256.1 is “newer than” kernel 5.8.1 - because 0x04010001 > 0x00050801. And that’s a compatibility breaking change.
- scns 6y agoSorry for nitpicking, the problem from the article is about the patch number. Your reasoning is still holds though: 0x00050801 (5.8.1 8b for patch) < 0x04090100 (4.9.256 16b for patch)
- josephg 6y agoOh oops - thanks for the correction! I somehow misread the article to be talking about 4.256.x instead of 4.x.256.
- dezgeg 6y agoIf your target audience is C, packing 3 values into one might even be the easiest to reason about, you get a single value that you can compare with the usual < and > etc. operators.
- dragontamer 6y agoAt some point, someone needs to point out the nonsense and just accept operator overloading... Or maybe writing a version_cmp function or similar.
- 0xbadcafebee 6y agoThe language already has an incredibly simple facility to compare version numbers (that GP mentions, but also there's macros), but you want to do it in a more complex way?
- mortehu 6y agoI don't understand your exact point, but the GNU C library ships with the strverscmp() and versionsort() functions, which do the same thing as `ls -v`.