require name
s be valid Antelope names when parsing from JSON
#37
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Prior to this change, when converting from JSON any
name
that was invalid (such as having longer than 13 characters, a disallowed character, etc) would be silently transformed in to a valid name by way of a hash.This results in surprising behavior at odds with nodeos where if, for example, serializing the following JSON to an eosio.token transfer,
will succeed. But with the invalid
bob bob bob
name being replaced with some 64-bit hash value.This PR now enforces that all
name
s be valid Antelope names when converting from JSON. The above JSON will fail to serialize. This new behavior is generally not expected to cause any problems nor need for any changes by code utilizing abieos because the prior silent hashing behavior was never something standardized in the Antelope ecosystem, including nodeos and cdt.However, there is one rare use case affected: consuming state_history's JSON ABI that is sent over state_history's websocket. This JSON ABI has table names that are not valid names, such as
contract_index64
.There is no way to access old behavior via abieos' C interface.
For C++, abieos retains the old behavior via
abi_def_nonstrict_table_name
and this can be used to handle state_history's ABI. A C++ state_history client that uses the JSON ABI sent over the websocket might start with something similar to,simply change the
from_json<>
line to,and this ABI will load as it did before.
To be clear, this issue arises only when consuming the JSON ABI from the websocket. Simply using the types in
ship_protocol.hpp
(which is oftentimes what a C++ state_history client does) will not be affected and no code changes are needed in such a case.Closes #31