Invalid plan arising from integer rounding

[bendbennett]

Overview

Issue 1

A lossy conversion between int64 and uint64 can arise because of the use of float64(), which has a precision of 53.

This issue arises in the following locations:

• value_msgpack.go#L77
• value_msgpack.go#L85
• value_msgpack.go#L91

Taking the form:

return NewValue(Number, big.NewFloat(float64(rv))), nil

Issue 2

Another potential lossy operation can arise from the usage of big.Float.Set.

This issue arises in the following location:

• value.go#L443

This is a consequence of the following:

v, ok := val.value.(*big.Float)
if !ok {
	return fmt.Errorf("can't unmarshal %s into %T, expected *big.Float", val.Type(), dst)
}
target.Set(v)

Because v uses the default precision of 53 of big.Float

An additional consequence of using target.Set(v) is that the tests within value_msgpack_test.go would not detect this form of rounding.

Fixes

• new(big.Float).SetInt64() or new(big.Float).SetUint64() is used as appropriate in value_msgpack.go.
• big.Float.Copy instead of big.Float.Set is used within value.go.
• Tests within value_msgpack_test.go have been updated to check for rounding.

Related Issues

• Closes Invalid plan arising from integer rounding #189

[detro]

👨‍🍳 😘

[bflad]

Looks good to me, just needs a CHANGELOG entry added, e.g. in .changelog/190.txt

```release-note:bug
tftypes: Prevented loss of number precision with integers between 54 and 64 bits
```

[github-actions]

I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active contributions.
If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.