Previously 59 tests were failing in the conformance tests. These were
failing in SINT32 and JSON enum handling. In both cases, we need to cast
int64 values to int32 to avoid losing bytes in a big-endian system.
Closes https://github.com/protocolbuffers/upb/issues/449
The output size is stored as `size_t`, a 64-bit value. However, on a
big-endian system this would be truncated to 0 since the low memory
addresses wold be sent.
To fix this, we cast the `size_t` to `uint32_t` and send that. Note that
calling `htonl()` would also work, but casting is simpler and does not
require including platform-specific header files.
Note that the tests now run, but there are 59 unexpected failures.
Closes https://github.com/protocolbuffers/upb/issues/446
In a big-endian system, the 64-bit value of 1 is represented as:
```
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x1
```
However, when `d.int32_val` is used, this truncates this and takes the
first four bytes:
```
0x0 0x0 0x0 0x0
```
As a result, we lose the value of 1 from this truncation and the value
beocmes 0. This doesn't happen in a little-endian system because the 1
is in the lowest memory address, so truncating the value to 32 bits
doesn't change anything.
Previously the DefToProto test was failing on a big-endian system
because this truncation caused the key to be incorrectly set to 0.
We now use the type-specific functions
(e.g. `upb_fielddef_defaultint32`) to do this conversion.
Closes https://github.com/protocolbuffers/upb/issues/442
As discussed in https://github.com/protocolbuffers/upb/issues/439, the
LUA binding tests were failing on some compilers (e.g. s390x) since
conversion of out-of-range integers values (e.g. 2^64 or
18446744073709551616) to a double can lead to undefined behavior. On
some compilers, this conversion can return 0, but it can also return the
max value.
To make this check work across platforms, we do the following:
1. Break the double into its integral and fractional components.
2. If there any fractional components, return an error.
3. Compare the min and max values in an intelligent way. We can't simply
compare against UINT64_MAX since that value will get implicitly
converted to a double in an undefined way, and 18446744073709551616 >
UINT64_MAX can return false. Instead, we can use the largest power of
two and use ldexp to generate the max value.
Closes https://github.com/protocolbuffers/upb/issues/439
Previously using an enum for a field on big-endian process such as the
s390x would fail to decode properly. We need to munge it in the correct
byte order before decoding it.
Joshua Haberman
Stan Hu