They could have compensated for this by adding an appropriate amount to the final value (wasting a bit of memory), but nooo... so the thing is as likely to error on the low side as on the high side, and they actually managed to introduce a security hole while trying to fix another one. A security hole that I'm fairly sure nobody else has ever introduced (how many floating-point rounding memory allocation bugs can there be in the world?)
Posted Apr 18, 2012 18:26 UTC (Wed) by juliank (subscriber, #45896)
[Link]
I also count byte sizes in floating point to avoid overflows, but certainly not for memory allocations. No problem for me, as my code does not have to be very fast when calculating things. And because I convert to floating point anyway, as I want to display human-readable sizes with %.3f digits.
PHP: a fractal of bad design (fuzzy notepad)
Posted Apr 18, 2012 23:34 UTC (Wed) by cmccabe (guest, #60281)
[Link]
I doubt that using floats rather than 64-bit integers is saving you any typing.
PHP: a fractal of bad design (fuzzy notepad)
Posted Apr 19, 2012 8:15 UTC (Thu) by juliank (subscriber, #45896)
[Link]
It doesn't when counting, but since I have to convert to double later on anyway, I can just count in double as well.
I could perhaps rewrite the human-readable size formatting to use integers (i.e. print B,KiB,MiB,GiB, TiB), but if I want precision after the period, things will start to get more complicated. And I usually want that precision.