Message type Int64 and UInt64 are greater than Number.MAX_SAFE_INTEGER

[qiuzhong]

The Int64 and UInt64 message type use string as the data property for inside representations. This might not a problem. However, part of numbers in this size are greater than Number.MAX_SAFE_INTEGER. So the data precision may be lost when delivering a Int64 or UInt64 number from publisher to subscription.

[minggangw]

We'd better combine this with #51

[minggangw]

The maximum integer JavaScript can represents is Number.MAX_SAFE_INTEGER, which is 2^53 - 1. But ROS can use uint64_t to represent a value, which has maximum value of 2^64 - 1.Considering the fact that rclcpp and rclpy can support UInt64 message and the compatibility problem, I think we'd better reserve the actual value of UInt64 in string by leveraging the ref, thus user can get the correct value in string instead of cutting of the value or throwing an exception, also user should have the consciousness that the maximum integer is Number.MAX_SAFE_INTEGER in JavaScript when using parseInt.

[minggangw]

I suggest maintaining the compatibility with other ros clients, which have the ability to represent Int64/UInt64. To achieve this, we have to store the int value as a string and let the user balance the interest, when the actual value is greater than Number.MAX_SAFE_INTEGER.

[minggangw]

Let me close this issue as we don't want lost any information from other client when using Int64/UInt64, and the caller should be aware of using a string to represent the Int64/UInt64 value.

[qiuzhong]

It's acceptable as the JavaScript integer implementation limit.