Rob Landley wrote: > >> The new patches have *more* environmental >> dependencies than that ever did. > > Could you please be a little more specific? > In this case, you're assuming that every version of every shell this is going to get involved with is going to do math correctly with the requisite precision, which is nowhere guaranteed, I'm pretty sure. >> Third, if someone actually cares to do it right, I have a smallish >> bignum library at http://git.zytor.com/?p=lib/pbn.git;a=summary that >> might be a starting point. > > This doesn't _need_ bignum support. It maxes out around 72 bits and the > _result_ can't use more than about $SHIFT bits because you're dividing by the > amount you shifted, so just chop off the bottom 32 bits, do a normal 64 bit > division on the top (it has to fit), and then do the same division on the > appropriate shifted remainder, and combine the results. This is easy because > when the shift _is_ 32 bits or more, the bottom 32 bits all have to be zeroes > so you don't even have to mask and add, just shift the remainder left 32 bits > so you can continue the divide. > > Pulling out perl isn't always a good alternative to thinking about the > problem. > Neither is open-coding a bignum operation instead of relying on an existing, validated implementation. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
