From ddccd73a4b8f7748f808bf0302773c6be671f253 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Kamil=20=C5=9Aliwak?= Date: Thu, 8 Jul 2021 13:04:00 +0200 Subject: [PATCH] Fix outdated references to `byte[]` type (it's now `bytes1[]`) --- docs/assembly.rst | 2 +- docs/internals/layout_in_memory.rst | 2 +- docs/types/reference-types.rst | 6 +++--- docs/types/value-types.rst | 2 +- 4 files changed, 6 insertions(+), 6 deletions(-) diff --git a/docs/assembly.rst b/docs/assembly.rst index 4e35ca702..9da8ebb8b 100644 --- a/docs/assembly.rst +++ b/docs/assembly.rst @@ -234,7 +234,7 @@ This means that the allocatable memory starts at ``0x80``, which is the initial of the free memory pointer. Elements in memory arrays in Solidity always occupy multiples of 32 bytes (this is -even true for ``byte[]``, but not for ``bytes`` and ``string``). Multi-dimensional memory +even true for ``bytes1[]``, but not for ``bytes`` and ``string``). Multi-dimensional memory arrays are pointers to memory arrays. The length of a dynamic array is stored at the first slot of the array and followed by the array elements. diff --git a/docs/internals/layout_in_memory.rst b/docs/internals/layout_in_memory.rst index 66623572f..8c20b6252 100644 --- a/docs/internals/layout_in_memory.rst +++ b/docs/internals/layout_in_memory.rst @@ -19,7 +19,7 @@ Solidity always places new objects at the free memory pointer and memory is never freed (this might change in the future). Elements in memory arrays in Solidity always occupy multiples of 32 bytes (this -is even true for ``byte[]``, but not for ``bytes`` and ``string``). +is even true for ``bytes1[]``, but not for ``bytes`` and ``string``). Multi-dimensional memory arrays are pointers to memory arrays. The length of a dynamic array is stored at the first slot of the array and followed by the array elements. diff --git a/docs/types/reference-types.rst b/docs/types/reference-types.rst index b6a36fc6e..7b1b541f3 100644 --- a/docs/types/reference-types.rst +++ b/docs/types/reference-types.rst @@ -139,7 +139,7 @@ a reference to it. ``bytes`` and ``string`` as Arrays ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Variables of type ``bytes`` and ``string`` are special arrays. A ``bytes`` is similar to ``byte[]``, +Variables of type ``bytes`` and ``string`` are special arrays. The ``bytes`` type is similar to ``bytes1[]``, but it is packed tightly in calldata and memory. ``string`` is equal to ``bytes`` but does not allow length or index access. @@ -148,8 +148,8 @@ third-party string libraries. You can also compare two strings by their keccak25 ``keccak256(abi.encodePacked(s1)) == keccak256(abi.encodePacked(s2))`` and concatenate two strings using ``bytes.concat(bytes(s1), bytes(s2))``. -You should use ``bytes`` over ``byte[]`` because it is cheaper, -since ``byte[]`` adds 31 padding bytes between the elements. As a general rule, +You should use ``bytes`` over ``bytes1[]`` because it is cheaper, +since ``bytes1[]`` adds 31 padding bytes between the elements. As a general rule, use ``bytes`` for arbitrary-length raw byte data and ``string`` for arbitrary-length string (UTF-8) data. If you can limit the length to a certain number of bytes, always use one of the value types ``bytes1`` to ``bytes32`` because they are much cheaper. diff --git a/docs/types/value-types.rst b/docs/types/value-types.rst index d6a30d106..1e2c3abc2 100644 --- a/docs/types/value-types.rst +++ b/docs/types/value-types.rst @@ -398,7 +398,7 @@ Members: * ``.length`` yields the fixed length of the byte array (read-only). .. note:: - The type ``byte[]`` is an array of bytes, but due to padding rules, it wastes + The type ``bytes1[]`` is an array of bytes, but due to padding rules, it wastes 31 bytes of space for each element (except in storage). It is better to use the ``bytes`` type instead.