| > Gecko is base-60 a.k.a. sexagesimal Thanks for that. I was very confused as to why the value was about 7% larger than 16,777,216 (2²⁴), and not exactly that. But assuming a binary representation (!) having the subdivisions be slightly fewer than a power of 2 (60 being slighly less than 64) means that the whole number limit will be slightly over a power of two, meaning that 60 × 17,895,697 should be a power of 2 (give or take a bit of rounding). And if you do the multiplication, it's 1,073,741,820, which is... huh. 2³⁰ (- 4). Why not 2³¹ or 2³²? Looks like they could at least double the CSS length limit there, even while continuing to allow negative lengths. Edit: As we can see from the parent-linked source on line 36, there is: # define nscoord_MAX nscoord((1 << 30) - 1)
which confirms the limit, but doesn't say why 30 is used instead of 31.Edit2: Info in the commit message at https://github.com/mozilla/gecko-dev/commit/e632c1393ebedfda... nscoord_MAX is (1<<30) so that we can check for overflow *after* adding two nscoords.
Makes sense. |