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
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
Joshua Haberman
Stan Hu