expand_number(3)

The expand_number(3) function was originally written as a counterpart to
humanize_number(3).  As such, it returned a signed integer and at least
nominally tried to support negative numbers.  This did not work in
practice and in 2010, I “fixed” this by changing it to only support
positive numbers.  In hindsight, this was stupid.  I am now proposing to
fix it to a) accept negative numbers and b) accept only decimal numbers,
since that is what humanize_number(3) produces.

Can anyone think of anything that will break as a consequence?  Is
anyone using expand_number(3) in a context where it is natural to pass
in numbers in other bases than decimal, or numbers between INT64_MAX and
UINT64_MAX (which will no longer be supported)?

I'll note in passing that newfs(8) actually expects expand_number(3) to
support negative numbers...

DES
-- 
Dag-Erling Smørgrav - des@FreeBSD.org