Andrew Kubera

Does the branch in MR #121 fix the issue?

It did not. This line had a potential out of bounds error if the exponent was near the i64 boundary, and had to be shifted forward or backwards past the...

I casted a bunch of i64's to i128's before doing formatting stuff, and added some tests where the exponent is near the i64 boundary: https://github.com/akubera/bigdecimal-rs/blob/72818b7809066470f47df76442102c45497260a5/src/impl_fmt.rs#L563-L572 Those test round-tripping, so everything...

Where did these issues come up? I know Python limits Decimal exponents to 10^18 (about 60 bits) and [Java uses 32-bit a scale](https://docs.oracle.com/javase/8/docs/api/java/math/BigDecimal.html) so I thought 64 bits would be...

Should be fixed in 0.4.3!

Ok, I'm working on this again. Going to split the first commit into move-existing-serde-to-impl-file, (I'll macro-tize the test) then apply your others and work something out.

I found a way to have my cake and eat it too. By aliasing the old version of serde_json for just tests, we can simultaneously support both versions: serde_json_testing restricted...

I don't like the name of the feature "arbitrary-precision", it only affects serialization and should reflect that. Otherwise it sounds like the library is fixed-precision unless otherwise enabled. Maybe `json-arbitrary-precision`,...

Other option would be... just don't test with serde_json on versions older than they support. which they CLAIM is 1.36, but they only test back to 1.56.

Going further and replacing serde_json with serde_test, which probably should have been used from the start. This gives us access to the Tokens serde uses, and we won't rely on...