- Stop using FixedArray. Memory allocators have improved since then, so the wins are smaller.
- Prevent allocating SpecificField object in the stack. It is 96 bytes and stays in the stack frame even if used temporarily in the function.
PiperOrigin-RevId: 534454119
This PR replaces the descriptor name validation regex with a validation method. This change allows the `System.Text.RegularExpressions` engine to be trimmed away in published apps that do standard protobuf serialization.
There are some other usages of `Regex` in Google.Protobuf, but they in `JsonParser`. They are only included in a published app if `JsonParser` is used.
Another benefit is a slightly faster app startup time. The removed regex was compiled, which has a high-ish fixed cost.
cc @jskeet@jtattermuschCloses#12174
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/12174 from JamesNK:jamesnk/remove-regex 9d065a3a71
PiperOrigin-RevId: 532210203
For legal reasons we unfortunately cannot accept any external contributions to
the well-known type protos, so this change reverts the small number of changes
we have received so far.
PiperOrigin-RevId: 517211904
- Reduce what headers the runtime import needs.
- Remove stale function prototype.
- Move one function to be full scoped to a single file.
PiperOrigin-RevId: 512073294
For PODs, parse the data before making the NSNumber used for extension
fields.
For messages/groups, create the message first, add it to the object graph,
and balance the retain count before doing the parsing. This ensure if an
error is hit (and a throw happens), the object(s) won't be leaked.
Parsing will always mutates the graph, so yes this includes more mutations
in failure cases, but other fields could always be modified before the
bad data is encountered. But even then, that edge case *only* apples to api
users that are explicitly *merge* (-mergeFrom...), the majority of the calls
are to +parseFromData:error:, so the entire graph is released on failure.
PiperOrigin-RevId: 511871398
The validation is done at the highest point so if a sub message is what
goes over the limit it is caught at the outer message, thus reducing the
impact on the serialization code.
PiperOrigin-RevId: 511473008
Add a helper to put the logic in one place in the file.
Ensure all places that read messages also do the 2GB check for message size.
PiperOrigin-RevId: 511260874
Add the objects to the object graph and balance the retain count before
doing the parsing. This ensure if an error is hit (and a throw happens),
the object(s) won't be leaked.
Parsing will always mutate the graph, so yes this includes more mutations
in failure cases, but other fields could always be modified before the
bad data is encountered. But even then, that edge case *only* apples to api
users that are explicitly *merge* (-mergeFrom...), the majority of the calls
are to +parseFromData:error:, so the entire graph is released on failure.
PiperOrigin-RevId: 510417377
The last attempted (rolled back) resulted in changes in visible behavior:
- It consumed a recursion depth on the input stream (wrong)
- It resulted in different error codes for some malformed/truncated data.
PiperOrigin-RevId: 510415215
Protobuf Team Bot
Protobuf Team Bot
Mike Kruskal
Matt Kulukundis
James Newton-King
Thomas Van Lenten
Deanna Garcia
Adam Cozzette