RevBank uses atomic file replacement by creating a new file and renaming
it over the old one. The newly created file is always in cwd, and
for the atomic rename() to work it must reside on the same filesystem as
the file it's replacing. Since File::Temp does the right thing and
creates files in /tmp by default, and /tmp is usually on a different
filesystem, these unit tests didn't actually work.
I don't know why they did work in the past. There doesn't seem to have
been any relevant change (or any at all, for that matter) to File::Temp,
which has had this behavior for ages. But I can't imagine that my /tmp
has only recently become a tmpfs mount either.
In any case, the issue is fixed by making File::Temp do the wrong thing,
which is to create its files in the cwd.
A sufficiently big number, i.e. longer than a long long, had interesting
effects. Perl would promote it to a float, and format it as -1 in
sprintf, which RevBank::Amount didn't handle correctly. In extreme cases
the number got rounded to Inf and would no longer round-trip.
As a result, numbers returned by RevBank::Amount are now Math::BigInt
and Math::BigFloat objects. Those should be transparent to all existing
code. It's amazing to see the unit tests pass.
I don't think there is any actual use case in RevBank for numbers this
large and I don't think anyone will have actually encountered the
aforementioned weird effects. Mostly, the input would be parsed with
parse_amount which refuses any number greater than 99900 anyway. Only
where parse_string was used directly, such large numbers could actually
have been used, but in stock RevBank that is only done when reading the
accounts file.
This change also introduces a new global function parse_any_amount that
is like parse_amount but doesn't complain about negative or large
numbers, to further improve the adduser plugin (see previous commit) in
insane edge cases. It differs from RevBank::Amount->parse_string in that
it does support addition and subtraction operators.
Was already implicitly required (since 59387ddb) because RevBank::Amount
uses the "isa" feature, which was introduced in Perl 5.32 (but no longer
experimental since 5.36, not 5.32 as the old comment said).
Perl 5.32 was released in June 2020, and ships with Debian bullseye
("oldstable") which was released in August 2021.
When asked to fix the bug, it came up with a different regex, which
would completely change what's valid and what's not, so that's totally
wrong:
/^\s*(-)?([0-9]+)(?:[,.]([0-9]{1,2}))?\s*$/
When asked to fix it in another way, without changing the regex, it
suggested stripping the sign completely, which is even more wrong.
So I fixed it myself :)
