User's Guide
Reference Manual
Release Notes
PDF
Top

Erlang Run-Time System Application (ERTS)
User's Guide
Version 5.10.2

Expand All
Contract All

Chapters

# 9 External Term Format

### 9.1 Introduction

The external term format is mainly used in the distribution mechanism of Erlang.

Since Erlang has a fixed number of types, there is no need for a programmer to define a specification for the external format used within some application. All Erlang terms has an external representation and the interpretation of the different terms are application specific.

In Erlang the BIF term_to_binary/1,2 is used to convert a term into the external format. To convert binary data encoding a term the BIF binary_to_term/1 is used.

The distribution does this implicitly when sending messages across node boundaries.

The overall format of the term format is:

1 | 1 | N
131 | Tag | Data

Table 9.1:
Note

When messages are passed between connected nodes and a distribution header is used, the first byte containing the version number (131) is omitted from the terms that follow the distribution header. This since the version number is implied by the version number in the distribution header.

A compressed term looks like this:

1 | 1 | 4 | N
131 | 80 | UncompressedSize | Zlib-compressedData

Table 9.2:

Uncompressed Size (unsigned 32 bit integer in big-endian byte order) is the size of the data before it was compressed. The compressed data has the following format when it has been expanded:

1 | Uncompressed Size
Tag | Data

Table 9.3:
Note

As of ERTS version 5.10 (OTP-R16) support for UTF-8 encoded atoms has been introduced in the external format. However, only characters that can be encoded using Latin1 (ISO-8859-1) are currently supported in atoms. The support for UTF-8 encoded atoms in the external format has been implemented in order to be able to support all Unicode characters in atoms in some future release. Full support for Unicode atoms will not happen before OTP-R18, and might be introduced even later than that. Until full Unicode support for atoms has been introduced, it is an error to pass atoms containing characters that cannot be encoded in Latin1, and the behavior is undefined.

When the DFLAG_UTF8_ATOMS distribution flag has been exchanged between both nodes in the distribution handshake, all atoms in the distribution header will be encoded in UTF-8; otherwise, all atoms in the distribution header will be encoded in Latin1. The two new tags ATOM_UTF8_EXT, and SMALL_ATOM_UTF8_EXT will only be used if the DFLAG_UTF8_ATOMS distribution flag has been exchanged between nodes, or if an atom containing characters that cannot be encoded in Latin1 is encountered.

The maximum number of allowed characters in an atom is 255. In the UTF-8 case each character may need 4 bytes to be encoded.

### 9.2 Distribution header

As of erts version 5.7.2 the old atom cache protocol was dropped and a new one was introduced. This atom cache protocol introduced the distribution header. Nodes with erts versions earlier than 5.7.2 can still communicate with new nodes, but no distribution header and no atom cache will be used.

The distribution header currently only contains an atom cache reference section, but could in the future contain more information. The distribution header precedes one or more Erlang terms on the external format. For more information see the documentation of the protocol between connected nodes in the distribution protocol documentation.

ATOM_CACHE_REF entries with corresponding AtomCacheReferenceIndex in terms encoded on the external format following a distribution header refers to the atom cache references made in the distribution header. The range is 0 <= AtomCacheReferenceIndex < 255, i.e., at most 255 different atom cache references from the following terms can be made.

The distribution header format is:

1 | 1 | 1 | NumberOfAtomCacheRefs/2+1 | 0 | N | 0
131 | 68 | NumberOfAtomCacheRefs | Flags | AtomCacheRefs

Table 9.4:

Flags consists of NumberOfAtomCacheRefs/2+1 bytes, unless NumberOfAtomCacheRefs is 0. If NumberOfAtomCacheRefs is 0, Flags and AtomCacheRefs are omitted. Each atom cache reference have a half byte flag field. Flags corresponding to a specific AtomCacheReferenceIndex, are located in flag byte number AtomCacheReferenceIndex/2. Flag byte 0 is the first byte after the NumberOfAtomCacheRefs byte. Flags for an even AtomCacheReferenceIndex are located in the least significant half byte and flags for an odd AtomCacheReferenceIndex are located in the most significant half byte.

The flag field of an atom cache reference has the following format:

1 bit | 3 bits
NewCacheEntryFlag | SegmentIndex

Table 9.5:

The most significant bit is the NewCacheEntryFlag. If set, the corresponding cache reference is new. The three least significant bits are the SegmentIndex of the corresponding atom cache entry. An atom cache consists of 8 segments each of size 256, i.e., an atom cache can contain 2048 entries.

After flag fields for atom cache references, another half byte flag field is located which has the following format:

3 bits | 1 bit
CurrentlyUnused | LongAtoms

Table 9.6:

The least significant bit in that half byte is the LongAtoms flag. If it is set, 2 bytes are used for atom lengths instead of 1 byte in the distribution header.

After the Flags field follow the AtomCacheRefs. The first AtomCacheRef is the one corresponding to AtomCacheReferenceIndex 0. Higher indices follows in sequence up to index NumberOfAtomCacheRefs - 1.

If the NewCacheEntryFlag for the next AtomCacheRef has been set, a NewAtomCacheRef on the following format will follow:

1 | 1 | 2 | Length
InternalSegmentIndex | Length | AtomText

Table 9.7:

InternalSegmentIndex together with the SegmentIndex completely identify the location of an atom cache entry in the atom cache. Length is number of bytes that AtomText consists of. Length is a two byte big endian integer if the LongAtoms flag has been set, otherwise a one byte integer. When the DFLAG_UTF8_ATOMS distribution flag has been exchanged between both nodes in the distribution handshake, characters in AtomText is encoded in UTF-8; otherwise, encoded in Latin1. Subsequent CachedAtomRefs with the same SegmentIndex and InternalSegmentIndex as this NewAtomCacheRef will refer to this atom until a new NewAtomCacheRef with the same SegmentIndex and InternalSegmentIndex appear.

For more information on encoding of atoms, see note on UTF-8 encoded atoms in the beginning of this document.

If the NewCacheEntryFlag for the next AtomCacheRef has not been set, a CachedAtomRef on the following format will follow:

1
InternalSegmentIndex

Table 9.8:

InternalSegmentIndex together with the SegmentIndex identify the location of the atom cache entry in the atom cache. The atom corresponding to this CachedAtomRef is the latest NewAtomCacheRef preceding this CachedAtomRef in another previously passed distribution header.

### 9.3 ATOM_CACHE_REF

1 | 1
82 | AtomCacheReferenceIndex

Table 9.9:

Refers to the atom with AtomCacheReferenceIndex in the distribution header.

### 9.4 SMALL_INTEGER_EXT

1 | 1
97 | Int

Table 9.10:

Unsigned 8 bit integer.

### 9.5 INTEGER_EXT

1 | 4
98 | Int

Table 9.11:

Signed 32 bit integer in big-endian format (i.e. MSB first)

### 9.6 FLOAT_EXT

1 | 31
99 | Float String

Table 9.12:

A float is stored in string format. the format used in sprintf to format the float is "%.20e" (there are more bytes allocated than necessary). To unpack the float use sscanf with format "%lf".

This term is used in minor version 0 of the external format; it has been superseded by NEW_FLOAT_EXT .

### 9.7 ATOM_EXT

1 | 2 | Len
100 | Len | AtomName

Table 9.13:

An atom is stored with a 2 byte unsigned length in big-endian order, followed by Len numbers of 8 bit Latin1 characters that forms the AtomName. Note: The maximum allowed value for Len is 255.

### 9.8 REFERENCE_EXT

1 | N | 4 | 1
101 | Node | ID | Creation

Table 9.14:

Encode a reference object (an object generated with make_ref/0). The Node term is an encoded atom, i.e. ATOM_EXT, SMALL_ATOM_EXT or ATOM_CACHE_REF. The ID field contains a big-endian unsigned integer, but should be regarded as uninterpreted data since this field is node specific. Creation is a byte containing a node serial number that makes it possible to separate old (crashed) nodes from a new one.

In ID, only 18 bits are significant; the rest should be 0. In Creation, only 2 bits are significant; the rest should be 0. See NEW_REFERENCE_EXT.

### 9.9 PORT_EXT

1 | N | 4 | 1
102 | Node | ID | Creation

Table 9.15:

Encode a port object (obtained form open_port/2). The ID is a node specific identifier for a local port. Port operations are not allowed across node boundaries. The Creation works just like in REFERENCE_EXT.

### 9.10 PID_EXT

1 | N | 4 | 4 | 1
103 | Node | ID | Serial | Creation

Table 9.16:

Encode a process identifier object (obtained from spawn/3 or friends). The ID and Creation fields works just like in REFERENCE_EXT, while the Serial field is used to improve safety. In ID, only 15 bits are significant; the rest should be 0.

### 9.11 SMALL_TUPLE_EXT

1 | 1 | N
104 | Arity | Elements

Table 9.17:

SMALL_TUPLE_EXT encodes a tuple. The Arity field is an unsigned byte that determines how many element that follows in the Elements section.

### 9.12 LARGE_TUPLE_EXT

1 | 4 | N
105 | Arity | Elements

Table 9.18:

Same as SMALL_TUPLE_EXT with the exception that Arity is an unsigned 4 byte integer in big endian format.

### 9.13 NIL_EXT

1
106

Table 9.19:

The representation for an empty list, i.e. the Erlang syntax [].

### 9.14 STRING_EXT

1 | 2 | Len
107 | Length | Characters

Table 9.20:

String does NOT have a corresponding Erlang representation, but is an optimization for sending lists of bytes (integer in the range 0-255) more efficiently over the distribution. Since the Length field is an unsigned 2 byte integer (big endian), implementations must make sure that lists longer than 65535 elements are encoded as LIST_EXT.

### 9.15 LIST_EXT

1 | 4 |  |
108 | Length | Elements | Tail

Table 9.21:

Length is the number of elements that follows in the Elements section. Tail is the final tail of the list; it is NIL_EXT for a proper list, but may be anything type if the list is improper (for instance [a|b]).

### 9.16 BINARY_EXT

1 | 4 | Len
109 | Len | Data

Table 9.22:

Binaries are generated with bit syntax expression or with list_to_binary/1, term_to_binary/1, or as input from binary ports. The Len length field is an unsigned 4 byte integer (big endian).

### 9.17 SMALL_BIG_EXT

1 | 1 | 1 | n
110 | n | Sign | d(0) ... d(n-1)

Table 9.23:

Bignums are stored in unary form with a Sign byte that is 0 if the binum is positive and 1 if is negative. The digits are stored with the LSB byte stored first. To calculate the integer the following formula can be used:
B = 256
(d0*B^0 + d1*B^1 + d2*B^2 + ... d(N-1)*B^(n-1))

### 9.18 LARGE_BIG_EXT

1 | 4 | 1 | n
111 | n | Sign | d(0) ... d(n-1)

Table 9.24:

Same as SMALL_BIG_EXT with the difference that the length field is an unsigned 4 byte integer.

### 9.19 NEW_REFERENCE_EXT

1 | 2 | N | 1 | N'
114 | Len | Node | Creation | ID ...

Table 9.25:

Node and Creation are as in REFERENCE_EXT.

ID contains a sequence of big-endian unsigned integers (4 bytes each, so N' is a multiple of 4), but should be regarded as uninterpreted data.

N' = 4 * Len.

In the first word (four bytes) of ID, only 18 bits are significant, the rest should be 0. In Creation, only 2 bits are significant, the rest should be 0.

NEW_REFERENCE_EXT was introduced with distribution version 4. In version 4, N' should be at most 12.

See REFERENCE_EXT).

### 9.20 SMALL_ATOM_EXT

1 | 1 | Len
115 | Len | AtomName

Table 9.26:

An atom is stored with a 1 byte unsigned length, followed by Len numbers of 8 bit Latin1 characters that forms the AtomName. Longer atoms can be represented by ATOM_EXT. Note the SMALL_ATOM_EXT was introduced in erts version 5.7.2 and require an exchange of the DFLAG_SMALL_ATOM_TAGS distribution flag in the distribution handshake.

### 9.21 FUN_EXT

1 | 4 | N1 | N2 | N3 | N4 | N5
117 | NumFree | Pid | Module | Index | Uniq | Free vars ...

Table 9.27:

Pid
  is a process identifier as in PID_EXT. It represents the process in which the fun was created.
Module
  is an encoded as an atom, using ATOM_EXT, SMALL_ATOM_EXT or ATOM_CACHE_REF. This is the module that the fun is implemented in.
Index
  is an integer encoded using SMALL_INTEGER_EXT or INTEGER_EXT. It is typically a small index into the module's fun table.
Uniq
  is an integer encoded using SMALL_INTEGER_EXT or INTEGER_EXT. Uniq is the hash value of the parse for the fun.
Free vars
  is NumFree number of terms, each one encoded according to its type.

### 9.22 NEW_FUN_EXT

1 | 4 | 1 | 16 | 4 | 4 | N1 | N2 | N3 | N4 | N5
112 | Size | Arity | Uniq | Index | NumFree | Module | OldIndex | OldUniq | Pid | Free Vars

Table 9.28:

This is the new encoding of internal funs: fun F/A and fun(Arg1,..) -> ... end.

Size
  is the total number of bytes, including the Size field.
Arity
  is the arity of the function implementing the fun.
Uniq
  is the 16 bytes MD5 of the significant parts of the Beam file.
Index
  is an index number. Each fun within a module has an unique index. Index is stored in big-endian byte order.
NumFree
  is the number of free variables.
Module
  is an encoded as an atom, using ATOM_EXT, SMALL_ATOM_EXT or ATOM_CACHE_REF. This is the module that the fun is implemented in.
OldIndex
  is an integer encoded using SMALL_INTEGER_EXT or INTEGER_EXT. It is typically a small index into the module's fun table.
OldUniq
  is an integer encoded using SMALL_INTEGER_EXT or INTEGER_EXT. Uniq is the hash value of the parse tree for the fun.
Pid
  is a process identifier as in PID_EXT. It represents the process in which the fun was created.
Free vars
  is NumFree number of terms, each one encoded according to its type.

### 9.23 EXPORT_EXT

1 | N1 | N2 | N3
113 | Module | Function | Arity

Table 9.29:

This term is the encoding for external funs: fun M:F/A.

Module and Function are atoms (encoded using ATOM_EXT, SMALL_ATOM_EXT or ATOM_CACHE_REF).

Arity is an integer encoded using SMALL_INTEGER_EXT.

### 9.24 BIT_BINARY_EXT

1 | 4 | 1 | Len
77 | Len | Bits | Data

Table 9.30:

This term represents a bitstring whose length in bits is not a multiple of 8 (created using the bit syntax in R12B and later). The Len field is an unsigned 4 byte integer (big endian). The Bits field is the number of bits that are used in the last byte in the data field, counting from the most significant bit towards the least significant.

### 9.25 NEW_FLOAT_EXT

1 | 8
70 | IEEE float

Table 9.31:

A float is stored as 8 bytes in big-endian IEEE format.

This term is used in minor version 1 of the external format.

### 9.26 ATOM_UTF8_EXT

1 | 2 | Len
118 | Len | AtomName

Table 9.32:

An atom is stored with a 2 byte unsigned length in big-endian order, followed by Len bytes containing the AtomName encoded in UTF-8.

For more information on encoding of atoms, see note on UTF-8 encoded atoms in the beginning of this document.

### 9.27 SMALL_ATOM_UTF8_EXT

1 | 1 | Len
119 | Len | AtomName

Table 9.33:

An atom is stored with a 1 byte unsigned length, followed by Len bytes containing the AtomName encoded in UTF-8. Longer atoms encoded in UTF-8 can be represented using ATOM_UTF8_EXT.

For more information on encoding of atoms, see note on UTF-8 encoded atoms in the beginning of this document.