This makes extension checking more strict in most cases.
However it also fixes a bug with MessageSet where we were being
too strict. MessageSet allows larger extension numbers than
normal extensions do.
Previously the encoder would serialize the output buffer in one copy,
but this only works on little-endian systems. For big-endian systems, we
now iterate through the array and convert each value if necessary before
serializing it out.
Closes https://github.com/protocolbuffers/upb/issues/436
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
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