From 57c3246511434f42214e113b8902af10ab9cca49 Mon Sep 17 00:00:00 2001 From: xsipewe Date: Tue, 21 Jun 2016 15:50:34 +0200 Subject: erts: Editorial changes --- erts/doc/src/erl_ext_dist.xml | 889 +++++++++++++++++++++--------------------- 1 file changed, 436 insertions(+), 453 deletions(-) (limited to 'erts/doc/src/erl_ext_dist.xml') diff --git a/erts/doc/src/erl_ext_dist.xml b/erts/doc/src/erl_ext_dist.xml index 2ac974f497..2ff0f39a3f 100644 --- a/erts/doc/src/erl_ext_dist.xml +++ b/erts/doc/src/erl_ext_dist.xml @@ -35,135 +35,130 @@
Introduction

- The external term format is mainly used in the distribution + 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 + As 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. + All Erlang terms have an external representation and the interpretation + of the different terms is 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 + In Erlang the BIF + erlang:term_to_binary/1,2 is used to convert a + term into the external format. + To convert binary data encoding to a term, the BIF - binary_to_term/1 - - is used. + erlang:binary_to_term/1c> is used.

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

- The overall format of the term format is: + The overall format of the term format is as follows:

- 1 - 1 - N + 1 + 1 + N - - 131 - Tag - Data - -
+ + 131 + Tag + Data + + Term Format -

- 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. -

+

+ 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 is because the version number is implied by the version + number in the distribution header. +

- A compressed term looks like this: + The compressed term format is as follows:

- 1 - 1 - 4 - N + 1 + 1 + 4 + N - 131 - 80 - UncompressedSize - Zlib-compressedData + 131 + 80 + UncompressedSize + Zlib-compressedData -
+ Compressed Term Format

- Uncompressed Size (unsigned 32 bit integer in big-endian byte order) + 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: + The compressed data has the following format when it has been expanded:

- 1 - Uncompressed Size + 1 + Uncompressed Size - Tag - Data + Tag + Data -
+ Compressed Data Format when Expanded -

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. - 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. -

+

As from ERTS 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 Latin-1 (ISO-8859-1) + are currently supported in atoms. The support for UTF-8 encoded atoms + in the external format has been implemented to be able to support + all Unicode characters in atoms in some future release. + Until full Unicode support for atoms has been introduced, + it is an error to pass atoms containing + characters that cannot be encoded in Latin-1, and the behavior is + undefined.

+

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

+

The maximum number of allowed characters in an atom is 255. In the + UTF-8 case, each character can need 4 bytes to be encoded.
- Distribution header + 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 + As from ERTS 5.7.2 the old atom cache protocol was + dropped and a new one was introduced. This protocol + introduced the distribution header. Nodes with an ERTS version earlier than 5.7.2 can still communicate with new nodes, - but no distribution header and no atom cache will be used.

+ but no distribution header and no atom cache are used.

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

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

- The distribution header format is: + The distribution header format is as follows:

- 1 - 1 - 1 - NumberOfAtomCacheRefs/2+1 | 0 - N | 0 + 1 + 1 + 1 + NumberOfAtomCacheRefs/2+1 | 0 + N | 0 - 131 - 68 - NumberOfAtomCacheRefs - Flags - AtomCacheRefs + 131 + 68 + NumberOfAtomCacheRefs + Flags + AtomCacheRefs -
+ Distribution Header Format

- Flags consists of NumberOfAtomCacheRefs/2+1 bytes, + Flags consist of NumberOfAtomCacheRefs/2+1 bytes, unless NumberOfAtomCacheRefs is 0. If NumberOfAtomCacheRefs is 0, Flags and - AtomCacheRefs are omitted. Each atom cache reference have + AtomCacheRefs are omitted. Each atom cache reference has a half byte flag field. Flags corresponding to a specific - AtomCacheReferenceIndex, are located in flag byte number + 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 @@ -216,95 +211,97 @@

- 1 bit - 3 bits + 1 bit + 3 bits - NewCacheEntryFlag - SegmentIndex + NewCacheEntryFlag + SegmentIndex

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. + atom cache entry. An atom cache consists of 8 segments, each of size + 256, that is, 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: + field is located with the following format:

- 3 bits - 1 bit + 3 bits + 1 bit - CurrentlyUnused - LongAtoms + CurrentlyUnused + LongAtoms

- 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 + The least significant bit in that half byte is flag LongAtoms. + 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 + AtomCacheReferenceIndex 0. Higher indices follow 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: + been set, a NewAtomCacheRef on the following format follows:

- 1 - 1 | 2 - Length + 1 + 1 | 2 + Length - InternalSegmentIndex - Length - AtomText + InternalSegmentIndex + Length + AtomText

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 + atom cache. Length is the number of bytes that AtomText + consists of. Length is a 2 byte big-endian integer + if flag LongAtoms has been set, otherwise a 1 byte + integer. When distribution flag + + DFLAG_UTF8_ATOMS + has been exchanged between both nodes in the + + distribution handshake, + characters in AtomText are encoded in UTF-8, otherwise + in Latin-1. The following CachedAtomRefs with the same SegmentIndex and InternalSegmentIndex as this - NewAtomCacheRef will refer to this atom until a new + NewAtomCacheRef refer to this atom until a new NewAtomCacheRef with the same SegmentIndex and InternalSegmentIndex appear.

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

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

- 1 + 1 - InternalSegmentIndex + InternalSegmentIndex

@@ -319,157 +316,147 @@

ATOM_CACHE_REF - 1 - 1 + 1 - 82 - AtomCacheReferenceIndex + 82 + AtomCacheReferenceIndex -
+ ATOM_CACHE_REF

Refers to the atom with AtomCacheReferenceIndex in the - distribution header. + distribution header.

SMALL_INTEGER_EXT - - 1 - 1 + 1 + 1 - 97 - Int + 97 + Int -
+ SMALL_INTEGER_EXT

- Unsigned 8 bit integer. + Unsigned 8-bit integer.

INTEGER_EXT - - 1 - 4 + 1 + 4 - 98 - Int + 98 + Int -
+ INTEGER_EXT

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

FLOAT_EXT - - 1 - 31 + 1 + 31 - 99 - Float String + 99 + Float string -
+ FLOAT_EXT

- A float is stored in string format. the format used in sprintf to - format the float is "%.20e" + 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". + 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 - . + This term is used in minor version 0 of the external format; + it has been superseded by + NEW_FLOAT_EXT.

ATOM_EXT - - 1 - 2 - Len + 1 + 2 + Len - 100 - Len - AtomName + 100 + Len + AtomName -
+ ATOM_EXT

- 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. + An atom is stored with a 2 byte unsigned length in big-endian order, + followed by Len numbers of 8-bit Latin-1 characters that forms + the AtomName. The maximum allowed value for Len is 255.

REFERENCE_EXT - - - - 1 - N - 4 - 1 - - - 101 - Node - ID - Creation - -
+ + + 1 + N + 4 + 1 + + + 101 + Node + ID + Creation + + REFERENCE_EXT

- 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. + Encodes a reference object (an object generated with + erlang:make_ref/0). + The Node term is an encoded atom, that is, + ATOM_EXT, + SMALL_ATOM_EXT, or + ATOM_CACHE_REF. + The ID field contains a big-endian unsigned integer, + but is to be regarded as uninterpreted data, + as this field is node-specific. + Creation is a byte containing a node serial number, which + 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. + In ID, only 18 bits are significant; the rest are to be 0. + In Creation, only two bits are significant; the rest are to be 0. + See + NEW_REFERENCE_EXT.

PORT_EXT - 1 @@ -483,20 +470,21 @@ ID Creation -
+ PORT_EXT

- Encode a port object (obtained form open_port/2). - The ID is a node specific identifier for a local port. + Encodes a port object (obtained from + + erlang: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. + REFERENCE_EXT.

PID_EXT - 1 @@ -512,23 +500,20 @@ Serial Creation -
+ PID_EXT

- 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. + Encodes a process identifier object (obtained from + erlang: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 are to be 0.

-
SMALL_TUPLE_EXT - 1 @@ -536,22 +521,21 @@ N - 104 - Arity - Elements + 104 + Arity + Elements -
+ SMALL_TUPLE_EXT

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

LARGE_TUPLE_EXT - 1 @@ -559,23 +543,22 @@ N - 105 - Arity - Elements + 105 + Arity + Elements -
+ LARGE_TUPLE_EXT

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

MAP_EXT - 1 @@ -583,43 +566,42 @@ N - 116 - Arity - Pairs + 116 + Arity + Pairs -
+ MAP_EXT

- MAP_EXT encodes a map. The Arity field is an unsigned - 4 byte integer in big endian format that determines the number of + Encodes a map. The Arity field is an unsigned + 4 byte integer in big-endian format that determines the number of key-value pairs in the map. Key and value pairs (Ki => Vi) - are encoded in the Pairs section in the following order: + are encoded in section Pairs in the following order: K1, V1, K2, V2,..., Kn, Vn. Duplicate keys are not allowed within the same map.

-

Since: OTP 17.0

+

As from Erlang/OTP 17.0

NIL_EXT - 1 - 106 + 106 -
+ NIL_EXT

- The representation for an empty list, i.e. the Erlang syntax []. + The representation for an empty list, that is, the Erlang syntax + [].

STRING_EXT - 1 @@ -627,27 +609,25 @@ Len - 107 - Length - Characters + 107 + Length + Characters -
+ STRING_EXT

- String does NOT have a corresponding Erlang representation, + 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. + As field Length is an unsigned 2 byte integer + (big-endian), implementations must ensure that lists longer than + 65535 elements are encoded as + LIST_EXT.

-
LIST_EXT - 1 @@ -656,27 +636,24 @@   - 108 - Length - Elements - Tail + 108 + Length + Elements + Tail -
- + LIST_EXT

- 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]). + Length is the number of elements that follows in section + Elements. Tail is the final tail of the list; it is + NIL_EXT + for a proper list, but can be any type if the list is + improper (for example, [a|b]).

BINARY_EXT - 1 @@ -684,25 +661,26 @@ Len - 109 - Len - Data + 109 + Len + Data -
+ BINARY_EXT

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

SMALL_BIG_EXT - 1 @@ -711,27 +689,26 @@ n - 110 - n - Sign - d(0) ... d(n-1) + 110 + n + Sign + d(0) ... d(n-1) -
+ SMALL_BIG_EXT

- 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)) + Bignums are stored in unary form with a Sign byte, + that is, 0 if the binum is positive and 1 if it is negative. The + digits are stored with the least significant 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))

LARGE_BIG_EXT - 1 @@ -740,24 +717,22 @@ n - 111 - n - Sign - d(0) ... d(n-1) + 111 + n + Sign + d(0) ... d(n-1) -
+ LARGE_BIG_EXT

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

-
NEW_REFERENCE_EXT - 1 @@ -767,44 +742,43 @@ N' - 114 - Len - Node - Creation - ID ... + 114 + Len + Node + Creation + ID ... -
+ NEW_REFERENCE_EXT

- Node and Creation are as in - REFERENCE_EXT. + 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. + ID contains a sequence of big-endian unsigned integers + (4 bytes each, so N' is a multiple of 4), + but is to 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. + In the first word (4 bytes) of ID, only 18 bits are + significant, the rest are to be 0. + In Creation, only two bits are significant, + the rest are to be 0.

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

- See REFERENCE_EXT). + See REFERENCE_EXT.

SMALL_ATOM_EXT - 1 @@ -816,24 +790,28 @@ Len AtomName -
+ SMALL_ATOM_EXT

- An atom is stored with a 1 byte unsigned length, - followed by Len numbers of 8 bit Latin1 characters that + An atom is stored with a 1 byte unsigned length, + followed by Len numbers of 8-bit Latin-1 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. + by ATOM_EXT.

+ +

+ SMALL_ATOM_EXT was introduced in ERTS 5.7.2 and + require an exchange of distribution flag + + DFLAG_SMALL_ATOM_TAGS in the + + distribution handshake. +

+
FUN_EXT - 1 @@ -845,48 +823,56 @@ N5 - 117 - NumFree - Pid - Module - Index - Uniq - Free vars ... + 117 + NumFree + Pid + Module + Index + Uniq + Free vars ... -
+ FUN_EXT - Pid + Pid - is a process identifier as in - PID_EXT. - It represents the process in which the fun was created. +

A process identifier as in + PID_EXT. + 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. +

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. +

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. +

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. +

NumFree number of terms, each one encoded according + to its type. +

@@ -894,7 +880,6 @@
NEW_FUN_EXT - 1 @@ -910,19 +895,19 @@ N5 - 112 - Size - Arity - Uniq - Index - NumFree - Module - OldIndex - OldUniq - Pid - Free Vars + 112 + Size + Arity + Uniq + Index + NumFree + Module + OldIndex + OldUniq + Pid + Free Vars -
+ NEW_FUN_EXT

This is the new encoding of internal funs: fun F/A and fun(Arg1,..) -> ... end. @@ -930,68 +915,73 @@ Size - is the total number of bytes, including the Size field. +

The total number of bytes, including field Size.

Arity - is the arity of the function implementing the fun. +

The arity of the function implementing the fun.

 Uniq - is the 16 bytes MD5 of the significant parts of the Beam file. +

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. +

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. +

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. +

Encoded as an atom, using + ATOM_EXT, + SMALL_ATOM_EXT, + or + ATOM_CACHE_REF. + 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. +

An integer encoded using + + SMALL_INTEGER_EXT or + INTEGER_EXT. + 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. +

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. +

A process identifier as in + PID_EXT. + Represents the process in which the fun was created. +

- Free vars - is NumFree number of terms, each one encoded according - to its type. +

NumFree number of terms, each one encoded according + to its type. +

- EXPORT_EXT - + EXPORT_EXT 1 @@ -1000,32 +990,31 @@ N3 - 113 - Module - Function - Arity + 113 + Module + Function + Arity -
+ EXPORT_EXT

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). + 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. + Arity is an integer encoded using + + SMALL_INTEGER_EXT.

-
BIT_BINARY_EXT - 1 @@ -1034,39 +1023,35 @@ Len - 77 - Len - Bits - Data + 77 + Len + Bits + Data -
+ BIT_BINARY_EXT

This term represents a bitstring whose length in bits does not have to be a multiple of 8. - The Len field is an unsigned 4 byte integer (big endian). + The Len field is an unsigned 4 byte integer (big-endian). The Bits field is the number of bits (1-8) that are used - in the last byte in the data field, - counting from the most significant bit towards the least - significant. + in the last byte in the data field, + counting from the most significant bit to the least significant.

- -
NEW_FLOAT_EXT - 1 8 - 70 - IEEE float + 70 + IEEE float -
+ NEW_FLOAT_EXT

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

@@ -1074,10 +1059,10 @@ This term is used in minor version 1 of the external format.

+
ATOM_UTF8_EXT - 1 @@ -1089,23 +1074,22 @@ Len AtomName -
+ ATOM_UTF8_EXT

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 + For more information on encoding of atoms, see the note on UTF-8 encoded atoms - in the beginning of this document. + in the beginning of this section.

SMALL_ATOM_UTF8_EXT - 1 @@ -1117,20 +1101,19 @@ Len AtomName -
+ SMALL_ATOM_UTF8_EXT

- An atom is stored with a 1 byte unsigned length, + 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. + ATOM_UTF8_EXT.

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

- - + -- cgit v1.2.3