Skip to content

Commit

Permalink
Add a note explaining return values not included in function signature
Browse files Browse the repository at this point in the history
  • Loading branch information
elenadimitrova committed Jan 3, 2018
1 parent efc198d commit 9a3402b
Showing 1 changed file with 8 additions and 0 deletions.
8 changes: 8 additions & 0 deletions docs/abi-spec.rst
Original file line number Diff line number Diff line change
Expand Up @@ -26,6 +26,12 @@ The first four bytes of the call data for a function call specifies the function
first (left, high-order in big-endian) four bytes of the Keccak (SHA-3) hash of the signature of the function. The signature is defined as the canonical expression of the basic prototype, i.e.
the function name with the parenthesised list of parameter types. Parameter types are split by a single comma - no spaces are used.

.. note::
Return type of the function is not taken into account. In :ref:`function overloading <overload-function>` it is difficult to determine what expressions are valid (function as right hand side vs lvalue).
and more importantly if the return value is not assigned to anything which one to take from a return-overloaded case.

The JSON description of the ABI contains both inputs and outputs. See (the :ref:`JSON ABI <abi_json>`)

Argument Encoding
=================

Expand Down Expand Up @@ -290,6 +296,8 @@ In effect, a log entry using this ABI is described as:

For all fixed-length Solidity types, the ``EVENT_INDEXED_ARGS`` array contains the 32-byte encoded value directly. However, for *types of dynamic length*, which include ``string``, ``bytes``, and arrays, ``EVENT_INDEXED_ARGS`` will contain the *Keccak hash* of the encoded value, rather than the encoded value directly. This allows applications to efficiently query for values of dynamic-length types (by setting the hash of the encoded value as the topic), but leaves applications unable to decode indexed values they have not queried for. For dynamic-length types, application developers face a trade-off between fast search for predetermined values (if the argument is indexed) and legibility of arbitrary values (which requires that the arguments not be indexed). Developers may overcome this tradeoff and achieve both efficient search and arbitrary legibility by defining events with two arguments — one indexed, one not — intended to hold the same value.

.. _abi_json:

JSON
====

Expand Down

0 comments on commit 9a3402b

Please sign in to comment.