aboutsummaryrefslogtreecommitdiffstats
path: root/lib/erl_interface
diff options
context:
space:
mode:
authorxsipewe <[email protected]>2016-10-20 11:46:03 +0200
committerBjörn-Egil Dahlberg <[email protected]>2016-10-20 14:10:04 +0200
commit031f9ca91ade7fbb9e31c82545401b8a5531e539 (patch)
treeab191bf48e2e67d99d8e03fd0482ec0f0897e519 /lib/erl_interface
parent9f5b69e8def226f1d1ce9262477d5bbd1cbc1fe7 (diff)
downloadotp-031f9ca91ade7fbb9e31c82545401b8a5531e539.tar.gz
otp-031f9ca91ade7fbb9e31c82545401b8a5531e539.tar.bz2
otp-031f9ca91ade7fbb9e31c82545401b8a5531e539.zip
erl_interface: Editorial changes
Diffstat (limited to 'lib/erl_interface')
-rw-r--r--lib/erl_interface/doc/src/ei.xml686
-rw-r--r--lib/erl_interface/doc/src/ei_connect.xml776
-rw-r--r--lib/erl_interface/doc/src/ei_users_guide.xml692
-rw-r--r--lib/erl_interface/doc/src/erl_call.xml196
-rw-r--r--lib/erl_interface/doc/src/erl_connect.xml546
-rw-r--r--lib/erl_interface/doc/src/erl_error.xml63
-rw-r--r--lib/erl_interface/doc/src/erl_eterm.xml588
-rw-r--r--lib/erl_interface/doc/src/erl_format.xml88
-rw-r--r--lib/erl_interface/doc/src/erl_global.xml122
-rw-r--r--lib/erl_interface/doc/src/erl_malloc.xml155
-rw-r--r--lib/erl_interface/doc/src/erl_marshal.xml258
-rw-r--r--lib/erl_interface/doc/src/part.xml2
-rw-r--r--lib/erl_interface/doc/src/ref_man.xml13
-rw-r--r--lib/erl_interface/doc/src/registry.xml680
14 files changed, 2774 insertions, 2091 deletions
diff --git a/lib/erl_interface/doc/src/ei.xml b/lib/erl_interface/doc/src/ei.xml
index 7928e4f5d1..6d416028a5 100644
--- a/lib/erl_interface/doc/src/ei.xml
+++ b/lib/erl_interface/doc/src/ei.xml
@@ -33,328 +33,368 @@
<file>ei.xml</file>
</header>
<lib>ei</lib>
- <libsummary>routines for handling the erlang binary term format</libsummary>
+ <libsummary>Routines for handling the Erlang binary term format.</libsummary>
<description>
<p>The library <c><![CDATA[ei]]></c> contains macros and functions to encode
- and decode the erlang binary term format.</p>
- <p>With <c><![CDATA[ei]]></c>, you can convert atoms, lists, numbers and
+ and decode the Erlang binary term format.</p>
+
+ <p><c><![CDATA[ei]]></c> allows you to convert atoms, lists, numbers, and
binaries to and from the binary format. This is useful when
writing port programs and drivers. <c><![CDATA[ei]]></c> uses a given
- buffer, and no dynamic memory (with the exception of
- <c><![CDATA[ei_decode_fun()]]></c>), and is often quite fast.</p>
- <p>It also handles C-nodes, C-programs that talks erlang
- distribution with erlang nodes (or other C-nodes) using the
- erlang distribution format. The difference between <c><![CDATA[ei]]></c> and
- <c><![CDATA[erl_interface]]></c> is that <c><![CDATA[ei]]></c> uses the binary format
- directly when sending and receiving terms. It is also thread
- safe, and using threads, one process can handle multiple
+ buffer, no dynamic memory (except
+ <c><![CDATA[ei_decode_fun()]]></c>) and is often quite fast.</p>
+
+ <p><c><![CDATA[ei]]></c> also handles C-nodes, C-programs that talks Erlang
+ distribution with Erlang nodes (or other C-nodes) using the
+ Erlang distribution format. The difference between <c><![CDATA[ei]]></c>
+ and <c><![CDATA[erl_interface]]></c> is that <c><![CDATA[ei]]></c> uses
+ the binary format directly when sending and receiving terms. It is also
+ thread safe, and using threads, one process can handle multiple
C-nodes. The <c><![CDATA[erl_interface]]></c> library is built on top of
- <c><![CDATA[ei]]></c>, but of legacy reasons, it doesn't allow for multiple
- C-nodes. In general, <c><![CDATA[ei]]></c> is the preferred way of doing
- C-nodes.</p>
- <p>The decode and encode functions use a buffer an index into the
+ <c><![CDATA[ei]]></c>, but of legacy reasons, it does not allow for
+ multiple C-nodes. In general, <c><![CDATA[ei]]></c> is the preferred way
+ of doing C-nodes.</p>
+
+ <p>The decode and encode functions use a buffer and an index into the
buffer, which points at the point where to encode and
decode. The index is updated to point right after the term
encoded/decoded. No checking is done whether the term fits in
the buffer or not. If encoding goes outside the buffer, the
- program may crash.</p>
- <p>All functions takes two parameter, <c><![CDATA[buf]]></c> is a pointer to
- the buffer where the binary data is / will be, <c><![CDATA[index]]></c> is a
- pointer to an index into the buffer. This parameter will be
- incremented with the size of the term decoded / encoded. The
- data is thus at <c><![CDATA[buf[*index]]]></c> when an <c><![CDATA[ei]]></c> function is
- called.</p>
- <p>The encode functions all assumes that the <c><![CDATA[buf]]></c> and
- <c><![CDATA[index]]></c> parameters points to a buffer big enough for the
- data. To get the size of an encoded term, without encoding it,
- pass <c><![CDATA[NULL]]></c> instead of a buffer pointer. The <c><![CDATA[index]]></c>
- parameter will be incremented, but nothing will be encoded. This
+ program can crash.</p>
+
+ <p>All functions take two parameters:</p>
+
+ <list type="bulleted">
+ <item><p><c><![CDATA[buf]]></c> is a pointer to
+ the buffer where the binary data is or will be.</p>
+ </item>
+ <item><p><c><![CDATA[index]]></c> is a pointer to an index into the
+ buffer. This parameter is incremented with the size of the term
+ decoded/encoded.</p>
+ </item>
+ </list>
+
+ <p>The data is thus at <c><![CDATA[buf[*index]]]></c> when an
+ <c><![CDATA[ei]]></c> function is called.</p>
+
+ <p>All encode functions assume that the <c><![CDATA[buf]]></c> and
+ <c><![CDATA[index]]></c> parameters point to a buffer large enough for
+ the data. To get the size of an encoded term, without encoding it,
+ pass <c><![CDATA[NULL]]></c> instead of a buffer pointer. Parameter
+ <c><![CDATA[index]]></c> is incremented, but nothing will be encoded. This
is the way in <c><![CDATA[ei]]></c> to "preflight" term encoding.</p>
- <p>There are also encode-functions that uses a dynamic buffer. It
+
+ <p>There are also encode functions that use a dynamic buffer. It
is often more convenient to use these to encode data. All encode
- functions comes in two versions: those starting with <c><![CDATA[ei_x]]></c>,
- uses a dynamic buffer.</p>
- <p>All functions return <c><![CDATA[0]]></c> if successful, and <c><![CDATA[-1]]></c> if
- not. (For instance, if a term is not of the expected type, or
- the data to decode is not a valid erlang term.)</p>
- <p>Some of the decode-functions needs a preallocated buffer. This
- buffer must be allocated big enough, and for non compound types
+ functions comes in two versions; those starting with
+ <c><![CDATA[ei_x]]></c> use a dynamic buffer.</p>
+
+ <p>All functions return <c><![CDATA[0]]></c> if successful, otherwise
+ <c><![CDATA[-1]]></c> (for example, if a term is not of the expected
+ type, or the data to decode is an invalid Erlang term).</p>
+
+ <p>Some of the decode functions need a pre-allocated buffer. This
+ buffer must be allocated large enough, and for non-compound types
the <c><![CDATA[ei_get_type()]]></c>
- function returns the size required (note that for strings an
+ function returns the size required (notice that for strings an
extra byte is needed for the 0 string terminator).</p>
</description>
- <section>
- <title>DATA TYPES</title>
+ <section>
+ <title>Data Types</title>
<taglist>
<tag><marker id="erlang_char_encoding"/>erlang_char_encoding</tag>
<item>
- <p/>
<code type="none">
typedef enum {
ERLANG_ASCII = 1,
ERLANG_LATIN1 = 2,
ERLANG_UTF8 = 4
-}erlang_char_encoding;
-</code>
- <p>The character encodings used for atoms. <c>ERLANG_ASCII</c> represents 7-bit ASCII.
- Latin1 and UTF8 are different extensions of 7-bit ASCII. All 7-bit ASCII characters
- are valid Latin1 and UTF8 characters. ASCII and Latin1 both represent each character
- by one byte. A UTF8 character can consist of one to four bytes. Note that these
- constants are bit-flags and can be combined with bitwise-or.</p>
+}erlang_char_encoding;</code>
+ <p>The character encodings used for atoms. <c>ERLANG_ASCII</c>
+ represents 7-bit ASCII. Latin-1 and UTF-8 are different extensions
+ of 7-bit ASCII. All 7-bit ASCII characters are valid Latin-1 and
+ UTF-8 characters. ASCII and Latin-1 both represent each character
+ by one byte. An UTF-8 character can consist of 1-4 bytes.
+ Notice that these
+ constants are bit-flags and can be combined with bitwise OR.</p>
</item>
</taglist>
</section>
+
<funcs>
<func>
<name><ret>int</ret><nametext>ei_decode_atom(const char *buf, int *index, char *p)</nametext></name>
<fsummary>Decode an atom.</fsummary>
<desc>
- <p>This function decodes an atom from the binary format. The
- null terminated name of the atom is placed at <c><![CDATA[p]]></c>. There can be at most
- <c><![CDATA[MAXATOMLEN]]></c> bytes placed in the buffer.</p>
+ <p>Decodes an atom from the binary format. The <c>NULL</c>-terminated
+ name of the atom is placed at <c><![CDATA[p]]></c>. At most
+ <c><![CDATA[MAXATOMLEN]]></c> bytes can be placed in the buffer.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_decode_atom_as(const char *buf, int *index, char *p, int plen, erlang_char_encoding want, erlang_char_encoding* was, erlang_char_encoding* result)</nametext></name>
<fsummary>Decode an atom.</fsummary>
<desc>
- <p>This function decodes an atom from the binary format. The
- null terminated name of the atom is placed in buffer at <c>p</c> of length
- <c>plen</c> bytes.</p>
- <p>The wanted string encoding is specified by <seealso marker="#erlang_char_encoding">
- <c>want</c></seealso>. The original encoding used in the
- binary format (latin1 or utf8) can be obtained from <c>*was</c>. The actual encoding of the resulting string
- (7-bit ascii, latin1 or utf8) can be obtained from <c>*result</c>. Both <c>was</c> and <c>result</c> can be <c>NULL</c>.
-
- <c>*result</c> may differ from <c>want</c> if <c>want</c> is a bitwise-or'd combination like
- <c>ERLANG_LATIN1|ERLANG_UTF8</c> or if <c>*result</c> turn out to be pure 7-bit ascii
- (compatible with both latin1 and utf8).</p>
+ <p>Decodes an atom from the binary format. The <c>NULL</c>-terminated
+ name of the atom is placed in buffer at <c>p</c> of length <c>plen</c>
+ bytes.</p>
+ <p>The wanted string encoding is specified by
+ <seealso marker="#erlang_char_encoding"><c>want</c></seealso>.
+ The original encoding used in the binary format (Latin-1 or UTF-8) can
+ be obtained from <c>*was</c>. The encoding of the resulting string
+ (7-bit ASCII, Latin-1, or UTF-8) can be obtained from <c>*result</c>.
+ Both <c>was</c> and <c>result</c> can be <c>NULL</c>. <c>*result</c>
+ can differ from <c>want</c> if <c>want</c> is a bitwise OR'd
+ combination like <c>ERLANG_LATIN1|ERLANG_UTF8</c> or if
+ <c>*result</c> turns out to be pure 7-bit ASCII
+ (compatible with both Latin-1 and UTF-8).</p>
<p>This function fails if the atom is too long for the buffer
- or if it can not be represented with encoding <c>want</c>.</p>
- <p>This function was introduced in R16 release of Erlang/OTP as part of a first step
- to support UTF8 atoms.</p>
+ or if it cannot be represented with encoding <c>want</c>.</p>
+ <p>This function was introduced in Erlang/OTP R16 as part of a first
+ step to support UTF-8 atoms.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_decode_bignum(const char *buf, int *index, mpz_t obj)</nametext></name>
<fsummary>Decode a GMP arbitrary precision integer.</fsummary>
<desc>
- <p>This function decodes an integer in the binary format to a GMP <c><![CDATA[mpz_t]]></c> integer.
- To use this function the ei library needs to be configured and compiled
- to use the GMP library. </p>
+ <p>Decodes an integer in the binary format to a GMP
+ <c><![CDATA[mpz_t]]></c> integer. To use this function, the <c>ei</c>
+ library must be configured and compiled to use the GMP library.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_decode_binary(const char *buf, int *index, void *p, long *len)</nametext></name>
<fsummary>Decode a binary.</fsummary>
<desc>
- <p>This function decodes a binary from the binary format. The
- <c><![CDATA[len]]></c> parameter is set to the actual size of the
- binary. Note that <c><![CDATA[ei_decode_binary()]]></c> assumes that there
- are enough room for the binary. The size required can be
+ <p>Decodes a binary from the binary format. Parameter
+ <c><![CDATA[len]]></c> is set to the actual size of the
+ binary. Notice that <c><![CDATA[ei_decode_binary()]]></c> assumes that
+ there is enough room for the binary. The size required can be
fetched by <c><![CDATA[ei_get_type()]]></c>.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_decode_boolean(const char *buf, int *index, int *p)</nametext></name>
<fsummary>Decode a boolean.</fsummary>
<desc>
- <p>This function decodes a boolean value from the binary
- format. A boolean is actually an atom, <c><![CDATA[true]]></c> decodes 1
+ <p>Decodes a boolean value from the binary format.
+ A boolean is actually an atom, <c><![CDATA[true]]></c> decodes 1
and <c><![CDATA[false]]></c> decodes 0.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_decode_char(const char *buf, int *index, char *p)</nametext></name>
<fsummary>Decode an 8-bit integer between 0-255.</fsummary>
<desc>
- <p>This function decodes a char (8-bit) integer between 0-255
- from the binary format.
- Note that for historical reasons the returned integer is of
- type <c><![CDATA[char]]></c>. Your C code should consider the
+ <p>Decodes a char (8-bit) integer between 0-255 from the binary format.
+ For historical reasons the returned integer is of
+ type <c><![CDATA[char]]></c>. Your C code is to consider the
returned value to be of type <c><![CDATA[unsigned char]]></c> even if
- the C compilers and system may define <c><![CDATA[char]]></c> to be
+ the C compilers and system can define <c><![CDATA[char]]></c> to be
signed.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_decode_double(const char *buf, int *index, double *p)</nametext></name>
<fsummary>Decode a double.</fsummary>
<desc>
- <p>This function decodes an double-precision (64 bit) floating
+ <p>Decodes a double-precision (64-bit) floating
point number from the binary format.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_decode_ei_term(const char* buf, int* index, ei_term* term)</nametext></name>
- <fsummary>Decode a term, without prior knowledge of type.</fsummary>
- <desc>
- <p>This function decodes any term, or at least tries to. If the
- term pointed at by <c><![CDATA[*index]]></c> in <c><![CDATA[buf]]></c> fits in the
- <c><![CDATA[term]]></c> union, it is decoded, and the appropriate field
- in <c><![CDATA[term->value]]></c> is set, and <c><![CDATA[*index]]></c> is
- incremented by the term size.</p>
- <p>The function returns 1 on successful decoding, -1 on error,
- and 0 if the term seems alright, but does not fit in the
- <c><![CDATA[term]]></c> structure. If it returns 1, the <c><![CDATA[index]]></c>
- will be incremented, and the <c><![CDATA[term]]></c> contains the
- decoded term.</p>
- <p>The <c><![CDATA[term]]></c> structure will contain the arity for a tuple
- or list, size for a binary, string or atom. It will contains
- a term if it's any of the following: integer, float, atom,
- pid, port or ref.</p>
+ <fsummary>Decode a term, without previous knowledge of type.</fsummary>
+ <desc>
+ <p>Decodes any term, or at least tries to. If the term
+ pointed at by <c><![CDATA[*index]]></c> in <c><![CDATA[buf]]></c> fits
+ in the <c><![CDATA[term]]></c> union, it is decoded, and the
+ appropriate field in <c><![CDATA[term->value]]></c> is set, and
+ <c><![CDATA[*index]]></c> is incremented by the term size.</p>
+ <p>The function returns <c>1</c> on successful decoding, <c>-1</c> on
+ error, and <c>0</c> if the term seems alright, but does not fit in the
+ <c><![CDATA[term]]></c> structure. If <c>1</c> is returned, the
+ <c><![CDATA[index]]></c> is incremented, and <c><![CDATA[term]]></c>
+ contains the decoded term.</p>
+ <p>The <c><![CDATA[term]]></c> structure contains the arity for a tuple
+ or list, size for a binary, string, or atom. It contains
+ a term if it is any of the following: integer, float, atom,
+ pid, port, or ref.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_decode_fun(const char *buf, int *index, erlang_fun *p)</nametext></name>
<name><ret>void</ret><nametext>free_fun(erlang_fun* f)</nametext></name>
<fsummary>Decode a fun.</fsummary>
<desc>
- <p>This function decodes a fun from the binary format. The
- <c><![CDATA[p]]></c> parameter should be NULL or point to an
+ <p>Decodes a fun from the binary format. Parameter
+ <c><![CDATA[p]]></c> is to be <c>NULL</c> or point to an
<c><![CDATA[erlang_fun]]></c> structure. This is the only decode
- function that allocates memory; when the <c><![CDATA[erlang_fun]]></c>
- is no longer needed, it should be freed with
- <c><![CDATA[free_fun]]></c>. (This has to do with the arbitrary size of
- the environment for a fun.)</p>
+ function that allocates memory. When the <c><![CDATA[erlang_fun]]></c>
+ is no longer needed, it is to be freed with
+ <c><![CDATA[free_fun]]></c>. (This has to do with the arbitrary size
+ of the environment for a fun.)</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_decode_list_header(const char *buf, int *index, int *arity)</nametext></name>
<fsummary>Decode a list.</fsummary>
<desc>
- <p>This function decodes a list header from the binary
+ <p>Decodes a list header from the binary
format. The number of elements is returned in
- <c><![CDATA[arity]]></c>. The <c><![CDATA[arity+1]]></c> elements follows (the last
- one is the tail of the list, normally an empty list.) If
- <c><![CDATA[arity]]></c> is <c><![CDATA[0]]></c>, it's an empty list.</p>
- <p>Note that lists are encoded as strings, if they consist
- entirely of integers in the range 0..255. This function will
+ <c><![CDATA[arity]]></c>. The <c><![CDATA[arity+1]]></c> elements
+ follow (the last one is the tail of the list, normally an empty list).
+ If <c><![CDATA[arity]]></c> is <c><![CDATA[0]]></c>, it is an empty
+ list.</p>
+ <p>Notice that lists are encoded as strings if they consist
+ entirely of integers in the range 0..255. This function do
not decode such strings, use <c><![CDATA[ei_decode_string()]]></c>
instead.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_decode_long(const char *buf, int *index, long *p)</nametext></name>
<fsummary>Decode integer.</fsummary>
<desc>
- <p>This function decodes a long integer from the binary format.
- Note that if the code is 64 bits the function ei_decode_long() is
- exactly the same as ei_decode_longlong().</p>
+ <p>Decodes a long integer from the binary format.
+ If the code is 64 bits, the function <c>ei_decode_long()</c> is
+ the same as <c>ei_decode_longlong()</c>.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_decode_longlong(const char *buf, int *index, long long *p)</nametext></name>
<fsummary>Decode integer.</fsummary>
<desc>
- <p>This function decodes a GCC <c><![CDATA[long long]]></c> or Visual C++ <c><![CDATA[__int64]]></c>
- (64 bit) integer from the binary format. Note that this
+ <p>Decodes a GCC <c><![CDATA[long long]]></c> or Visual C++
+ <c><![CDATA[__int64]]></c>
+ (64-bit) integer from the binary format. This
function is missing in the VxWorks port.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_decode_map_header(const char *buf, int *index, int *arity)</nametext></name>
<fsummary>Decode a map.</fsummary>
<desc>
- <p>This function decodes a map header from the binary
+ <p>Decodes a map header from the binary
format. The number of key-value pairs is returned in
- <c>*arity</c>. Keys and values follow in the following order:
+ <c>*arity</c>. Keys and values follow in this order:
<c>K1, V1, K2, V2, ..., Kn, Vn</c>. This makes a total of
- <c>arity*2</c> terms. If <c>arity</c> is zero, it's an empty map.
+ <c>arity*2</c> terms. If <c>arity</c> is zero, it is an empty map.
A correctly encoded map does not have duplicate keys.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_decode_pid(const char *buf, int *index, erlang_pid *p)</nametext></name>
<fsummary>Decode a <c><![CDATA[pid]]></c>.</fsummary>
<desc>
- <p>Decodes a pid, process identifier, from the binary format.</p>
+ <p>Decodes a process identifier (pid) from the binary format.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_decode_port(const char *buf, int *index, erlang_port *p)</nametext></name>
<fsummary>Decode a port.</fsummary>
<desc>
- <p>This function decodes a port identifier from the binary
- format.</p>
+ <p>Decodes a port identifier from the binary format.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_decode_ref(const char *buf, int *index, erlang_ref *p)</nametext></name>
<fsummary>Decode a reference.</fsummary>
<desc>
- <p>This function decodes a reference from the binary format.</p>
+ <p>Decodes a reference from the binary format.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_decode_string(const char *buf, int *index, char *p)</nametext></name>
<fsummary>Decode a string.</fsummary>
<desc>
- <p>This function decodes a string from the binary format. A
- string in erlang is a list of integers between 0 and
- 255. Note that since the string is just a list, sometimes
+ <p>Decodes a string from the binary format. A
+ string in Erlang is a list of integers between 0 and
+ 255. Notice that as the string is just a list, sometimes
lists are encoded as strings by <c><![CDATA[term_to_binary/1]]></c>,
even if it was not intended.</p>
- <p>The string is copied to <c><![CDATA[p]]></c>, and enough space must be
- allocated. The returned string is null terminated so you
- need to add an extra byte to the memory requirement.</p>
+ <p>The string is copied to <c><![CDATA[p]]></c>, and enough space must
+ be allocated. The returned string is <c>NULL</c>-terminated, so you
+ must add an extra byte to the memory requirement.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_decode_term(const char *buf, int *index, void *t)</nametext></name>
<fsummary>Decode a <c><![CDATA[ETERM]]></c>.</fsummary>
<desc>
- <p>This function decodes a term from the binary format. The
- term is return in <c><![CDATA[t]]></c> as a <c><![CDATA[ETERM*]]></c>, so <c><![CDATA[t]]></c>
- is actually an <c><![CDATA[ETERM**]]></c> (see
- <c><![CDATA[erl_interface(3)]]></c>. The term should later be
- deallocated.</p>
- <p>Note that this function is located in the erl_interface
+ <p>Decodes a term from the binary format. The term
+ is return in <c><![CDATA[t]]></c> as a <c><![CDATA[ETERM*]]></c>, so
+ <c><![CDATA[t]]></c> is actually an <c><![CDATA[ETERM**]]></c> (see
+ <seealso marker="erl_eterm"><c>erl_eterm</c></seealso>).
+ The term is later to be deallocated.</p>
+ <p>Notice that this function is located in the <c>Erl_Interface</c>
library.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_decode_trace(const char *buf, int *index, erlang_trace *p)</nametext></name>
<fsummary>Decode a trace token.</fsummary>
<desc>
- <p>Decodes an erlang trace token from the binary format.</p>
+ <p>Decodes an Erlang trace token from the binary format.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_decode_tuple_header(const char *buf, int *index, int *arity)</nametext></name>
<fsummary>Decode a tuple.</fsummary>
<desc>
- <p>This function decodes a tuple header, the number of elements
- is returned in <c><![CDATA[arity]]></c>. The tuple elements follows in order in
- the buffer.</p>
+ <p>Decodes a tuple header, the number of elements
+ is returned in <c><![CDATA[arity]]></c>. The tuple elements follow
+ in order in the buffer.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_decode_ulong(const char *buf, int *index, unsigned long *p)</nametext></name>
<fsummary>Decode unsigned integer.</fsummary>
<desc>
- <p>This function decodes an unsigned long integer from
- the binary format.
- Note that if the code is 64 bits the function ei_decode_ulong() is
- exactly the same as ei_decode_ulonglong().</p>
+ <p>Decodes an unsigned long integer from the binary format.
+ If the code is 64 bits, the function <c>ei_decode_ulong()</c> is
+ the same as <c>ei_decode_ulonglong()</c>.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_decode_ulonglong(const char *buf, int *index, unsigned long long *p)</nametext></name>
<fsummary>Decode unsigned integer.</fsummary>
<desc>
- <p>This function decodes a GCC <c><![CDATA[unsigned long long]]></c> or Visual C++
- <c><![CDATA[unsigned __int64]]></c> (64 bit) integer from the binary format.
- Note that this function is missing in the VxWorks port.</p>
+ <p>Decodes a GCC <c><![CDATA[unsigned long long]]></c> or Visual C++
+ <c><![CDATA[unsigned __int64]]></c> (64-bit) integer from the binary
+ format. This function is missing in the VxWorks port.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_decode_version(const char *buf, int *index, int *version)</nametext></name>
- <fsummary>Encode an empty list (<c><![CDATA[nil]]></c>).</fsummary>
+ <fsummary>Decode an empty list (<c><![CDATA[nil]]></c>).</fsummary>
<desc>
- <p>This function decodes the version magic number for the
- erlang binary term format. It must be the first token in a
+ <p>Decodes the version magic number for the
+ Erlang binary term format. It must be the first token in a
binary term.</p>
</desc>
</func>
@@ -366,12 +406,14 @@ typedef enum {
<name><ret>int</ret><nametext>ei_x_encode_atom_len(ei_x_buff* x, const char *p, int len)</nametext></name>
<fsummary>Encode an atom.</fsummary>
<desc>
- <p>Encodes an atom in the binary format. The <c><![CDATA[p]]></c> parameter
- is the name of the atom in latin1 encoding. Only upto <c>MAXATOMLEN-1</c> bytes
- are encoded. The name should be zero-terminated, except for
+ <p>Encodes an atom in the binary format. Parameter <c><![CDATA[p]]></c>
+ is the name of the atom in Latin-1 encoding. Only up to
+ <c>MAXATOMLEN-1</c> bytes
+ are encoded. The name is to be zero-terminated, except for
the <c><![CDATA[ei_x_encode_atom_len()]]></c> function.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_encode_atom_as(char *buf, int *index, const char *p, erlang_char_encoding from_enc, erlang_char_encoding to_enc)</nametext></name>
<name><ret>int</ret><nametext>ei_encode_atom_len_as(char *buf, int *index, const char *p, int len, erlang_char_encoding from_enc, erlang_char_encoding to_enc)</nametext></name>
@@ -380,30 +422,35 @@ typedef enum {
<fsummary>Encode an atom.</fsummary>
<desc>
<p>Encodes an atom in the binary format with character encoding
- <seealso marker="#erlang_char_encoding"><c>to_enc</c></seealso> (latin1 or utf8).
- The <c>p</c> parameter is the name of the atom with character encoding
- <seealso marker="#erlang_char_encoding"><c>from_enc</c></seealso> (ascii, latin1 or utf8).
- The name must either be zero-terminated or a function variant with a <c>len</c>
- parameter must be used. If <c>to_enc</c> is set to the bitwise-or'd combination
- <c>(ERLANG_LATIN1|ERLANG_UTF8)</c>, utf8 encoding is only used if the atom string
- can not be represented in latin1 encoding.</p>
- <p>The encoding will fail if <c>p</c> is not a valid string in encoding <c>from_enc</c>,
- if the string is too long or if it can not be represented with character encoding <c>to_enc</c>.</p>
- <p>These functions were introduced in R16 release of Erlang/OTP as part of a first step
- to support UTF8 atoms. Atoms encoded with <c>ERLANG_UTF8</c>
- can not be decoded by earlier releases than R16.</p>
+ <seealso marker="#erlang_char_encoding"><c>to_enc</c></seealso>
+ (Latin-1 or UTF-8). Parameter <c>p</c> is the name of the atom with
+ character encoding
+ <seealso marker="#erlang_char_encoding"><c>from_enc</c></seealso>
+ (ASCII, Latin-1, or UTF-8). The name must either be zero-terminated or
+ a function variant with a <c>len</c> parameter must be used.
+ If <c>to_enc</c> is set to the bitwise OR'd combination
+ <c>(ERLANG_LATIN1|ERLANG_UTF8)</c>, UTF-8 encoding is only used if the
+ atom string cannot be represented in Latin-1 encoding.</p>
+ <p>The encoding fails if <c>p</c> is an invalid string in encoding
+ <c>from_enc</c>, if the string is too long, or if it cannot be
+ represented with character encoding <c>to_enc</c>.</p>
+ <p>These functions were introduced in Erlang/OTP R16 as part of a first
+ step to support UTF-8 atoms. Atoms encoded with <c>ERLANG_UTF8</c>
+ cannot be decoded by earlier releases than R16.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_encode_bignum(char *buf, int *index, mpz_t obj)</nametext></name>
<name><ret>int</ret><nametext>ei_x_encode_bignum(ei_x_buff *x, mpz_t obj)</nametext></name>
<fsummary>Encode an arbitrary precision integer.</fsummary>
<desc>
<p>Encodes a GMP <c><![CDATA[mpz_t]]></c> integer to binary format.
- To use this function the ei library needs to be configured and compiled
- to use the GMP library. </p>
+ To use this function, the <c>ei</c> library must be configured and
+ compiled to use the GMP library.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_encode_binary(char *buf, int *index, const void *p, long len)</nametext></name>
<name><ret>int</ret><nametext>ei_x_encode_binary(ei_x_buff* x, const void *p, long len)</nametext></name>
@@ -413,72 +460,78 @@ typedef enum {
<c><![CDATA[p]]></c>, of <c><![CDATA[len]]></c> bytes length.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_encode_boolean(char *buf, int *index, int p)</nametext></name>
<name><ret>int</ret><nametext>ei_x_encode_boolean(ei_x_buff* x, int p)</nametext></name>
<fsummary>Encode a boolean.</fsummary>
<desc>
- <p>Encodes a boolean value, as the atom <c><![CDATA[true]]></c> if p is not
- zero or <c><![CDATA[false]]></c> if p is zero.</p>
+ <p>Encodes a boolean value as the atom <c><![CDATA[true]]></c> if
+ <c>p</c> is not zero, or <c><![CDATA[false]]></c> if <c>p</c> is
+ zero.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_encode_char(char *buf, int *index, char p)</nametext></name>
<name><ret>int</ret><nametext>ei_x_encode_char(ei_x_buff* x, char p)</nametext></name>
<fsummary>Encode an 8-bit integer between 0-255.</fsummary>
<desc>
- <p>Encodes a char (8-bit) as an integer between 0-255 in the binary format.
- Note that for historical reasons the integer argument is of
- type <c><![CDATA[char]]></c>. Your C code should consider the
- given argument to be of type <c><![CDATA[unsigned char]]></c> even if
+ <p>Encodes a char (8-bit) as an integer between 0-255 in the binary
+ format. For historical reasons the integer argument is of
+ type <c><![CDATA[char]]></c>. Your C code is to consider the specified
+ argument to be of type <c><![CDATA[unsigned char]]></c> even if
the C compilers and system may define <c><![CDATA[char]]></c> to be
signed.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_encode_double(char *buf, int *index, double p)</nametext></name>
<name><ret>int</ret><nametext>ei_x_encode_double(ei_x_buff* x, double p)</nametext></name>
<fsummary>Encode a double float.</fsummary>
<desc>
- <p>Encodes a double-precision (64 bit) floating point number in
+ <p>Encodes a double-precision (64-bit) floating point number in
the binary format.</p>
- <p>
- The function returns <c><![CDATA[-1]]></c> if the floating point number is not finite.
- </p>
+ <p>Returns <c><![CDATA[-1]]></c> if the floating point
+ number is not finite.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_encode_empty_list(char* buf, int* index)</nametext></name>
<name><ret>int</ret><nametext>ei_x_encode_empty_list(ei_x_buff* x)</nametext></name>
<fsummary>Encode an empty list (<c><![CDATA[nil]]></c>).</fsummary>
<desc>
- <p>This function encodes an empty list. It's often used at the
- tail of a list.</p>
+ <p>Encodes an empty list. It is often used at the tail of a list.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_encode_fun(char *buf, int *index, const erlang_fun *p)</nametext></name>
<name><ret>int</ret><nametext>ei_x_encode_fun(ei_x_buff* x, const erlang_fun* fun)</nametext></name>
<fsummary>Encode a fun.</fsummary>
<desc>
- <p>Encodes a fun in the binary format. The <c><![CDATA[p]]></c> parameter
+ <p>Encodes a fun in the binary format. Parameter <c><![CDATA[p]]></c>
points to an <c><![CDATA[erlang_fun]]></c> structure. The
<c><![CDATA[erlang_fun]]></c> is not freed automatically, the
- <c><![CDATA[free_fun]]></c> should be called if the fun is not needed
+ <c><![CDATA[free_fun]]></c> is to be called if the fun is not needed
after encoding.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_encode_list_header(char *buf, int *index, int arity)</nametext></name>
<name><ret>int</ret><nametext>ei_x_encode_list_header(ei_x_buff* x, int arity)</nametext></name>
<fsummary>Encode a list.</fsummary>
<desc>
- <p>This function encodes a list header, with a specified
+ <p>Encodes a list header, with a specified
arity. The next <c><![CDATA[arity+1]]></c> terms are the elements
(actually its <c><![CDATA[arity]]></c> cons cells) and the tail of the
list. Lists and tuples are encoded recursively, so that a
- list may contain another list or tuple.</p>
- <p>E.g. to encode the list <c><![CDATA[[c, d, [e | f]]]]></c>:</p>
+ list can contain another list or tuple.</p>
+ <p>For example, to encode the list
+ <c><![CDATA[[c, d, [e | f]]]]></c>:</p>
<pre>
ei_encode_list_header(buf, &amp;i, 3);
ei_encode_atom(buf, &amp;i, "c");
@@ -486,14 +539,13 @@ ei_encode_atom(buf, &amp;i, "d");
ei_encode_list_header(buf, &amp;i, 1);
ei_encode_atom(buf, &amp;i, "e");
ei_encode_atom(buf, &amp;i, "f");
-ei_encode_empty_list(buf, &amp;i);
- </pre>
+ei_encode_empty_list(buf, &amp;i);</pre>
<note>
<p>It may seem that there is no way to create a list without
knowing the number of elements in advance. But indeed
- there is a way. Note that the list <c><![CDATA[[a, b, c]]]></c> can be
- written as <c><![CDATA[[a | [b | [c]]]]]></c>. Using this, a list can
- be written as conses.</p>
+ there is a way. Notice that the list <c><![CDATA[[a, b, c]]]></c>
+ can be written as <c><![CDATA[[a | [b | [c]]]]]></c>.
+ Using this, a list can be written as conses.</p>
</note>
<p>To encode a list, without knowing the arity in advance:</p>
<pre>
@@ -501,83 +553,89 @@ while (something()) {
ei_x_encode_list_header(&amp;x, 1);
ei_x_encode_ulong(&amp;x, i); /* just an example */
}
-ei_x_encode_empty_list(&amp;x);
- </pre>
+ei_x_encode_empty_list(&amp;x);</pre>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_encode_long(char *buf, int *index, long p)</nametext></name>
<name><ret>int</ret><nametext>ei_x_encode_long(ei_x_buff* x, long p)</nametext></name>
<fsummary>Encode integer.</fsummary>
<desc>
<p>Encodes a long integer in the binary format.
- Note that if the code is 64 bits the function ei_encode_long() is
- exactly the same as ei_encode_longlong().</p>
+ If the code is 64 bits, the function <c>ei_encode_long()</c> is
+ the same as <c>ei_encode_longlong()</c>.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_encode_longlong(char *buf, int *index, long long p)</nametext></name>
<name><ret>int</ret><nametext>ei_x_encode_longlong(ei_x_buff* x, long long p)</nametext></name>
<fsummary>Encode integer.</fsummary>
<desc>
- <p>Encodes a GCC <c><![CDATA[long long]]></c> or Visual C++ <c><![CDATA[__int64]]></c> (64 bit)
- integer in the binary format. Note that this function is missing
- in the VxWorks port.</p>
+ <p>Encodes a GCC <c><![CDATA[long long]]></c> or Visual C++
+ <c><![CDATA[__int64]]></c> (64-bit) integer in the binary format.
+ This function is missing in the VxWorks port.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_encode_map_header(char *buf, int *index, int arity)</nametext></name>
<name><ret>int</ret><nametext>ei_x_encode_map_header(ei_x_buff* x, int arity)</nametext></name>
<fsummary>Encode a map.</fsummary>
<desc>
- <p>This function encodes a map header, with a specified arity. The next
+ <p>Encodes a map header, with a specified arity. The next
<c>arity*2</c> terms encoded will be the keys and values of the map
encoded in the following order: <c>K1, V1, K2, V2, ..., Kn, Vn</c>.
</p>
- <p>E.g. to encode the map <c>#{a => "Apple", b => "Banana"}</c>:</p>
+ <p>For example, to encode the map <c>#{a => "Apple", b =>
+ "Banana"}</c>:</p>
<pre>
ei_x_encode_map_header(&amp;x, 2);
ei_x_encode_atom(&amp;x, "a");
ei_x_encode_string(&amp;x, "Apple");
ei_x_encode_atom(&amp;x, "b");
-ei_x_encode_string(&amp;x, "Banana");
- </pre>
- <p>A correctly encoded map can not have duplicate keys.</p>
+ei_x_encode_string(&amp;x, "Banana");</pre>
+ <p>A correctly encoded map cannot have duplicate keys.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_encode_pid(char *buf, int *index, const erlang_pid *p)</nametext></name>
<name><ret>int</ret><nametext>ei_x_encode_pid(ei_x_buff* x, const erlang_pid *p)</nametext></name>
<fsummary>Encode a pid.</fsummary>
<desc>
- <p>Encodes an erlang process identifier, pid, in the binary
- format. The <c><![CDATA[p]]></c> parameter points to an
- <c><![CDATA[erlang_pid]]></c> structure (which should have been obtained
- earlier with <c><![CDATA[ei_decode_pid()]]></c>).</p>
+ <p>Encodes an Erlang process identifier (pid) in the binary
+ format. Parameter <c><![CDATA[p]]></c> points to an
+ <c><![CDATA[erlang_pid]]></c> structure (which should have been
+ obtained earlier with <c><![CDATA[ei_decode_pid()]]></c>).</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_encode_port(char *buf, int *index, const erlang_port *p)</nametext></name>
<name><ret>int</ret><nametext>ei_x_encode_port(ei_x_buff* x, const erlang_port *p)</nametext></name>
- <fsummary>Encodes a port.</fsummary>
+ <fsummary>Encode a port.</fsummary>
<desc>
- <p>Encodes an erlang port in the binary format. The <c><![CDATA[p]]></c>
- parameter points to a <c><![CDATA[erlang_port]]></c> structure (which
- should have been obtained earlier with
- <c><![CDATA[ei_decode_port()]]></c>.</p>
+ <p>Encodes an Erlang port in the binary format. Parameter
+ <c><![CDATA[p]]></c> points to a <c><![CDATA[erlang_port]]></c>
+ structure (which should have been obtained earlier with
+ <c><![CDATA[ei_decode_port()]]></c>).</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_encode_ref(char *buf, int *index, const erlang_ref *p)</nametext></name>
<name><ret>int</ret><nametext>ei_x_encode_ref(ei_x_buff* x, const erlang_ref *p)</nametext></name>
- <fsummary>Encodes a ref.</fsummary>
+ <fsummary>Encode a ref.</fsummary>
<desc>
- <p>Encodes an erlang reference in the binary format. The
- <c><![CDATA[p]]></c> parameter points to a <c><![CDATA[erlang_ref]]></c> structure
- (which should have been obtained earlier with
- <c><![CDATA[ei_decode_ref()]]></c>.</p>
+ <p>Encodes an Erlang reference in the binary format. Parameter
+ <c><![CDATA[p]]></c> points to a <c><![CDATA[erlang_ref]]></c>
+ structure (which should have been obtained earlier with
+ <c><![CDATA[ei_decode_ref()]]></c>).</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_encode_string(char *buf, int *index, const char *p)</nametext></name>
<name><ret>int</ret><nametext>ei_encode_string_len(char *buf, int *index, const char *p, int len)</nametext></name>
@@ -585,21 +643,22 @@ ei_x_encode_string(&amp;x, "Banana");
<name><ret>int</ret><nametext>ei_x_encode_string_len(ei_x_buff* x, const char* s, int len)</nametext></name>
<fsummary>Encode a string.</fsummary>
<desc>
- <p>Encodes a string in the binary format. (A string in erlang
+ <p>Encodes a string in the binary format. (A string in Erlang
is a list, but is encoded as a character array in the binary
- format.) The string should be zero-terminated, except for
+ format.) The string is to be zero-terminated, except for
the <c><![CDATA[ei_x_encode_string_len()]]></c> function.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_encode_term(char *buf, int *index, void *t)</nametext></name>
<name><ret>int</ret><nametext>ei_x_encode_term(ei_x_buff* x, void *t)</nametext></name>
- <fsummary>Encode an <c><![CDATA[erl_interface]]></c>term.</fsummary>
+ <fsummary>Encode an <c><![CDATA[erl_interface]]></c> term.</fsummary>
<desc>
- <p>This function encodes an <c><![CDATA[ETERM]]></c>, as obtained from
- <c><![CDATA[erl_interface]]></c>. The <c><![CDATA[t]]></c> parameter is actually an
- <c><![CDATA[ETERM]]></c> pointer. This function doesn't free the
- <c><![CDATA[ETERM]]></c>.</p>
+ <p>Encodes an <c><![CDATA[ETERM]]></c>, as obtained from
+ <c><![CDATA[erl_interface]]></c>. Parameter <c><![CDATA[t]]></c> is
+ actually an <c><![CDATA[ETERM]]></c> pointer. This function
+ does not free the <c><![CDATA[ETERM]]></c>.</p>
</desc>
</func>
<func>
@@ -607,51 +666,54 @@ ei_x_encode_string(&amp;x, "Banana");
<name><ret>int</ret><nametext>ei_x_encode_trace(ei_x_buff* x, const erlang_trace *p)</nametext></name>
<fsummary>Encode a trace token.</fsummary>
<desc>
- <p>This function encodes an erlang trace token in the binary
- format. The <c><![CDATA[p]]></c> parameter points to a
+ <p>Encodes an Erlang trace token in the binary format.
+ Parameter <c><![CDATA[p]]></c> points to a
<c><![CDATA[erlang_trace]]></c> structure (which should have been
- obtained earlier with <c><![CDATA[ei_decode_trace()]]></c>.</p>
+ obtained earlier with <c><![CDATA[ei_decode_trace()]]></c>).</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_encode_tuple_header(char *buf, int *index, int arity)</nametext></name>
<name><ret>int</ret><nametext>ei_x_encode_tuple_header(ei_x_buff* x, int arity)</nametext></name>
<fsummary>Encode a tuple.</fsummary>
<desc>
- <p>This function encodes a tuple header, with a specified
+ <p>Encodes a tuple header, with a specified
arity. The next <c><![CDATA[arity]]></c> terms encoded will be the
elements of the tuple. Tuples and lists are encoded
- recursively, so that a tuple may contain another tuple or
- list.</p>
- <p>E.g. to encode the tuple <c><![CDATA[{a, {b, {}}}]]></c>:</p>
+ recursively, so that a tuple can contain another tuple or list.</p>
+ <p>For example, to encode the tuple <c><![CDATA[{a, {b, {}}}]]></c>:</p>
<pre>
ei_encode_tuple_header(buf, &amp;i, 2);
ei_encode_atom(buf, &amp;i, "a");
ei_encode_tuple_header(buf, &amp;i, 2);
ei_encode_atom(buf, &amp;i, "b");
-ei_encode_tuple_header(buf, &amp;i, 0);
- </pre>
+ei_encode_tuple_header(buf, &amp;i, 0);</pre>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_encode_ulong(char *buf, int *index, unsigned long p)</nametext></name>
<name><ret>int</ret><nametext>ei_x_encode_ulong(ei_x_buff* x, unsigned long p)</nametext></name>
<fsummary>Encode unsigned integer.</fsummary>
<desc>
<p>Encodes an unsigned long integer in the binary format.
- Note that if the code is 64 bits the function ei_encode_ulong() is
- exactly the same as ei_encode_ulonglong().</p>
+ If the code is 64 bits, the function <c>ei_encode_ulong()</c> is
+ the same as <c>ei_encode_ulonglong()</c>.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_encode_ulonglong(char *buf, int *index, unsigned long long p)</nametext></name>
<name><ret>int</ret><nametext>ei_x_encode_ulonglong(ei_x_buff* x, unsigned long long p)</nametext></name>
<fsummary>Encode unsigned integer.</fsummary>
<desc>
- <p>Encodes a GCC <c><![CDATA[unsigned long long]]></c> or Visual C++ <c><![CDATA[unsigned __int64]]></c> (64 bit) integer in the binary format. Note that
- this function is missing in the VxWorks port.</p>
+ <p>Encodes a GCC <c><![CDATA[unsigned long long]]></c> or Visual C++
+ <c><![CDATA[unsigned __int64]]></c> (64-bit) integer in the binary
+ format. This function is missing in the VxWorks port.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_encode_version(char *buf, int *index)</nametext></name>
<name><ret>int</ret><nametext>ei_x_encode_version(ei_x_buff* x)</nametext></name>
@@ -661,43 +723,47 @@ ei_encode_tuple_header(buf, &amp;i, 0);
be the first token in a binary term.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_get_type(const char *buf, const int *index, int *type, int *size)</nametext></name>
<fsummary>Fetch the type and size of an encoded term.</fsummary>
<desc>
- <p>This function returns the type in <c><![CDATA[type]]></c> and size in
- <c><![CDATA[size]]></c> of the encoded term.
- For strings and atoms, size
- is the number of characters <em>not</em> including the
+ <p>Returns the type in <c><![CDATA[type]]></c> and size in
+ <c><![CDATA[size]]></c> of the encoded term. For strings and atoms,
+ size is the number of characters <em>not</em> including the
terminating 0. For binaries, <c><![CDATA[size]]></c> is the number of
- bytes. For lists and tuples, <c><![CDATA[size]]></c> is the arity of the
- object. For other types, <c><![CDATA[size]]></c> is 0. In all cases,
- <c><![CDATA[index]]></c> is left unchanged.</p>
+ bytes. For lists and tuples, <c><![CDATA[size]]></c> is the arity of
+ the object. For other types, <c><![CDATA[size]]></c> is 0. In all
+ cases, <c><![CDATA[index]]></c> is left unchanged.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_print_term(FILE* fp, const char* buf, int* index)</nametext></name>
<name><ret>int</ret><nametext>ei_s_print_term(char** s, const char* buf, int* index)</nametext></name>
<fsummary>Print a term in clear text.</fsummary>
<desc>
- <p>This function prints a term, in clear text, to the file
- given by <c><![CDATA[fp]]></c>, or the buffer pointed to by <c><![CDATA[s]]></c>. It
- tries to resemble the term printing in the erlang shell.</p>
- <p>In <c><![CDATA[ei_s_print_term()]]></c>, the parameter <c><![CDATA[s]]></c> should
+ <p>Prints a term, in clear text, to the file
+ specified by <c><![CDATA[fp]]></c>, or the buffer pointed to by
+ <c><![CDATA[s]]></c>. It
+ tries to resemble the term printing in the Erlang shell.</p>
+ <p>In <c><![CDATA[ei_s_print_term()]]></c>, parameter
+ <c><![CDATA[s]]></c> is to
point to a dynamically (malloc) allocated string of
- <c><![CDATA[BUFSIZ]]></c> bytes or a NULL pointer. The string may be
- reallocated (and <c><![CDATA[*s]]></c> may be updated) by this function
- if the result is more than <c><![CDATA[BUFSIZ]]></c> characters. The
- string returned is zero-terminated.</p>
- <p>The return value is the number of characters written to the
- file or string, or -1 if <c><![CDATA[buf[index]]]></c> doesn't contain a
- valid term. Unfortunately, I/O errors on <c><![CDATA[fp]]></c> is not
- checked.</p>
- <p>The argument <c><![CDATA[index]]></c> is updated, i.e. this function can
- be viewed as en decode function that decodes a term into a
- human readable format.</p>
+ <c><![CDATA[BUFSIZ]]></c> bytes or a <c>NULL</c> pointer. The string
+ can be reallocated (and <c><![CDATA[*s]]></c> can be updated) by this
+ function if the result is more than <c><![CDATA[BUFSIZ]]></c>
+ characters. The string returned is zero-terminated.</p>
+ <p>The return value is the number of characters written to the file
+ or string, or <c>-1</c> if <c><![CDATA[buf[index]]]></c> does not
+ contain a valid term.
+ Unfortunately, I/O errors on <c><![CDATA[fp]]></c> is not checked.</p>
+ <p>Argument <c><![CDATA[index]]></c> is updated, that is, this function
+ can be viewed as a decode function that decodes a term into a
+ human-readable format.</p>
</desc>
</func>
+
<func>
<name><ret>void</ret><nametext>ei_set_compat_rel(release_number)</nametext></name>
<fsummary>Set the ei library in compatibility mode.</fsummary>
@@ -708,54 +774,58 @@ ei_encode_tuple_header(buf, &amp;i, 0);
<marker id="ei_set_compat_rel"></marker>
<p>By default, the <c><![CDATA[ei]]></c> library is only guaranteed
to be compatible with other Erlang/OTP components from the same
- release as the <c><![CDATA[ei]]></c> library itself. For example, <c><![CDATA[ei]]></c> from
- the OTP R10 release is not compatible with an Erlang emulator
- from the OTP R9 release by default.</p>
- <p>A call to <c><![CDATA[ei_set_compat_rel(release_number)]]></c> sets the
- <c><![CDATA[ei]]></c> library in compatibility mode of release
- <c><![CDATA[release_number]]></c>. Valid range of <c><![CDATA[release_number]]></c>
- is [7, current release]. This makes it possible to
+ release as the <c><![CDATA[ei]]></c> library itself. For example,
+ <c><![CDATA[ei]]></c> from
+ Erlang/OTP R10 is not compatible with an Erlang emulator
+ from Erlang/OTP R9 by default.</p>
+ <p>A call to <c><![CDATA[ei_set_compat_rel(release_number)]]></c> sets
+ the <c><![CDATA[ei]]></c> library in compatibility mode of release
+ <c><![CDATA[release_number]]></c>. Valid range of
+ <c><![CDATA[release_number]]></c>
+ is <c>[7, current release]</c>. This makes it possible to
communicate with Erlang/OTP components from earlier releases.</p>
<note>
- <p>If this function is called, it may only be called once
- and must be called before any other functions in the <c><![CDATA[ei]]></c>
- library is called.</p>
+ <p>If this function is called, it can only be called once
+ and must be called before any other functions in the
+ <c><![CDATA[ei]]></c> library are called.</p>
</note>
<warning>
- <p>You may run into trouble if this feature is used
- carelessly. Always make sure that all communicating
+ <p>You can run into trouble if this feature is used
+ carelessly. Always ensure that all communicating
components are either from the same Erlang/OTP release, or
from release X and release Y where all components
from release Y are in compatibility mode of release X.</p>
</warning>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_skip_term(const char* buf, int* index)</nametext></name>
- <fsummary>skip a term.</fsummary>
+ <fsummary>Skip a term.</fsummary>
<desc>
- <p>This function skips a term in the given buffer, it
+ <p>Skips a term in the specified buffer;
recursively skips elements of lists and tuples, so that a
full term is skipped. This is a way to get the size of an
- erlang term.</p>
+ Erlang term.</p>
<p><c><![CDATA[buf]]></c> is the buffer.</p>
- <p><c><![CDATA[index]]></c> is updated to point right after the term in the
- buffer.</p>
+ <p><c><![CDATA[index]]></c> is updated to point right after the term
+ in the buffer.</p>
<note>
<p>This can be useful when you want to hold arbitrary
- terms: just skip them and copy the binary term data to some
+ terms: skip them and copy the binary term data to some
buffer.</p>
</note>
- <p>The function returns <c><![CDATA[0]]></c> on success and <c><![CDATA[-1]]></c> on
- failure.</p>
+ <p>Returns <c><![CDATA[0]]></c> on success, otherwise
+ <c><![CDATA[-1]]></c>.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_x_append(ei_x_buff* x, const ei_x_buff* x2)</nametext></name>
<name><ret>int</ret><nametext>ei_x_append_buf(ei_x_buff* x, const char* buf, int len)</nametext></name>
- <fsummary>Appends a buffer at the end.</fsummary>
+ <fsummary>Append a buffer at the end.</fsummary>
<desc>
- <p>These functions appends data at the end of the buffer <c><![CDATA[x]]></c>.</p>
+ <p>Appends data at the end of buffer <c><![CDATA[x]]></c>.</p>
</desc>
</func>
@@ -764,69 +834,69 @@ ei_encode_tuple_header(buf, &amp;i, 0);
<name><ret>int</ret><nametext>ei_x_format_wo_ver(ei_x_buff* x, const char *fmt, ... )</nametext></name>
<fsummary>Format a term from a format string and parameters.</fsummary>
<desc>
- <p>Format a term, given as a string, to a buffer. This
- functions works like a sprintf for erlang terms. The
+ <p>Formats a term, given as a string, to a buffer.
+ Works like a sprintf for Erlang terms.
<c><![CDATA[fmt]]></c> contains a format string, with arguments like
<c><![CDATA[~d]]></c>, to insert terms from variables. The following
formats are supported (with the C types given):</p>
- <p></p>
<pre>
-~a - an atom, char*
-~c - a character, char
-~s - a string, char*
-~i - an integer, int
-~l - a long integer, long int
-~u - a unsigned long integer, unsigned long int
-~f - a float, float
-~d - a double float, double float
-~p - an Erlang PID, erlang_pid*
- </pre>
- <p>For instance, to encode a tuple with some stuff:</p>
+~a An atom, char*
+~c A character, char
+~s A string, char*
+~i An integer, int
+~l A long integer, long int
+~u A unsigned long integer, unsigned long int
+~f A float, float
+~d A double float, double float
+~p An Erlang pid, erlang_pid*</pre>
+ <p>For example, to encode a tuple with some stuff:</p>
<pre>
ei_x_format("{~a,~i,~d}", "numbers", 12, 3.14159)
-encodes the tuple {numbers,12,3.14159}
- </pre>
- <p>The <c><![CDATA[ei_x_format_wo_ver()]]></c> formats into a buffer, without
- the initial version byte.</p>
+encodes the tuple {numbers,12,3.14159}</pre>
+ <p><c><![CDATA[ei_x_format_wo_ver()]]></c> formats into a buffer,
+ without the initial version byte.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_x_free(ei_x_buff* x)</nametext></name>
- <fsummary>Frees a buffer.</fsummary>
+ <fsummary>Free a buffer.</fsummary>
<desc>
- <p>This function frees an <c><![CDATA[ei_x_buff]]></c> buffer. The memory
- used by the buffer is returned to the OS.</p>
+ <p>Frees an <c><![CDATA[ei_x_buff]]></c> buffer.
+ The memory used by the buffer is returned to the OS.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_x_new(ei_x_buff* x)</nametext></name>
<name><ret>int</ret><nametext>ei_x_new_with_version(ei_x_buff* x)</nametext></name>
<fsummary>Allocate a new buffer.</fsummary>
<desc>
- <p>This function allocates a new <c><![CDATA[ei_x_buff]]></c> buffer. The
- fields of the structure pointed to by <c><![CDATA[x]]></c> parameter is
- filled in, and a default buffer is allocated. The
- <c><![CDATA[ei_x_new_with_version()]]></c> also puts an initial version
- byte, that is used in the binary format. (So that
- <c><![CDATA[ei_x_encode_version()]]></c> won't be needed.)</p>
+ <p>Allocates a new <c><![CDATA[ei_x_buff]]></c> buffer. The
+ fields of the structure pointed to by parameter <c><![CDATA[x]]></c>
+ is filled in, and a default buffer is allocated.
+ <c><![CDATA[ei_x_new_with_version()]]></c> also puts an initial
+ version byte, which is used in the binary format (so that
+ <c><![CDATA[ei_x_encode_version()]]></c> will not be needed.)</p>
</desc>
</func>
- </funcs>
+ </funcs>
<section>
<title>Debug Information</title>
- <p>Some tips on what to check when the emulator doesn't seem to
- receive the terms that you send.</p>
+ <p>Some tips on what to check when the emulator does not seem to
+ receive the terms that you send:</p>
+
<list type="bulleted">
- <item>be careful with the version header, use
- <c><![CDATA[ei_x_new_with_version()]]></c> when appropriate</item>
- <item>turn on distribution tracing on the erlang node</item>
- <item>check the result codes from ei_decode_-calls</item>
+ <item>Be careful with the version header, use
+ <c><![CDATA[ei_x_new_with_version()]]></c> when appropriate.</item>
+ <item>Turn on distribution tracing on the Erlang node.</item>
+ <item>Check the result codes from <c>ei_decode_-calls</c>.</item>
</list>
</section>
<section>
<title>See Also</title>
- <p>erl_interface(3)</p>
+ <p><seealso marker="erl_eterm"><c>erl_eterm</c></seealso></p>
</section>
</cref>
diff --git a/lib/erl_interface/doc/src/ei_connect.xml b/lib/erl_interface/doc/src/ei_connect.xml
index 8cc08f86cd..a5a020ffda 100644
--- a/lib/erl_interface/doc/src/ei_connect.xml
+++ b/lib/erl_interface/doc/src/ei_connect.xml
@@ -25,57 +25,66 @@
<title>ei_connect</title>
<prepared>Jakob Cederlund</prepared>
<docno></docno>
- <approved>?</approved>
- <checked>?</checked>
+ <approved></approved>
+ <checked></checked>
<date>2001-09-01</date>
<rev>A</rev>
<file>ei_connect.xml</file>
</header>
<lib>ei_connect</lib>
- <libsummary>Communicate with distributed erlang</libsummary>
+ <libsummary>Communicate with distributed Erlang.</libsummary>
<description>
- <p>This module enables C programs to communicate with erlang nodes,
- using the erlang distribution over TCP/IP.</p>
- <p>A C node appears to Erlang as a
- <em>hidden node</em>.
+ <p>This module enables C-programs to communicate with Erlang nodes,
+ using the Erlang distribution over TCP/IP.</p>
+
+ <p>A C-node appears to Erlang as a <em>hidden node</em>.
That is, Erlang processes that know the name of the
- C node are able to communicate with it in a normal manner, but
- the node name will not appear in the listing provided by the
- Erlang function <c><![CDATA[nodes/0]]></c>.</p>
+ C-node can communicate with it in a normal manner, but
+ the node name is not shown in the listing provided by
+ <seealso marker="erts:erlang#nodes/0"><c>erlang:nodes/0</c></seealso>
+ in <c>ERTS</c>.</p>
+
<p>The environment variable <c><![CDATA[ERL_EPMD_PORT]]></c> can be used
- to indicate which logical cluster a C node belongs to.</p>
+ to indicate which logical cluster a C-node belongs to.</p>
</description>
<section>
- <title>Timeout functions</title>
+ <title>Time-Out Functions</title>
<p>Most functions appear in a version with the suffix
- <c><![CDATA[_tmo]]></c> appended to the function name. Those function take
- an additional argument, a timeout in <em>milliseconds</em>. The
- semantics is this; for each communication primitive involved in
+ <c><![CDATA[_tmo]]></c> appended to the function name. Those functions
+ take an extra argument, a time-out in <em>milliseconds</em>. The
+ semantics is this: for each communication primitive involved in
the operation, if the primitive does not complete within the time
- specified, the function will return an error and
- <c><![CDATA[erl_errno]]></c> will be set to <c><![CDATA[ETIMEDOUT]]></c>. With
- communication primitive is meant an operation on the socket, like
- <c><![CDATA[connect]]></c>, <c><![CDATA[accept]]></c>, <c><![CDATA[recv]]></c> or <c><![CDATA[send]]></c>.</p>
- <p>Obviously the timeouts are for implementing fault tolerance,
- not to keep hard realtime promises. The <c><![CDATA[_tmo]]></c> functions
+ specified, the function returns an error and
+ <c><![CDATA[erl_errno]]></c> is set to <c><![CDATA[ETIMEDOUT]]></c>.
+ With communication primitive is meant an operation on the socket, like
+ <c><![CDATA[connect]]></c>, <c><![CDATA[accept]]></c>,
+ <c><![CDATA[recv]]></c>, or <c><![CDATA[send]]></c>.</p>
+
+ <p>Clearly the time-outs are for implementing fault tolerance,
+ not to keep hard real-time promises. The <c><![CDATA[_tmo]]></c> functions
are for detecting non-responsive peers and to avoid blocking on
- socket operations. </p>
- <p>A timeout value of <c><![CDATA[0]]></c> (zero), means that timeouts are
- disabled. Calling a <c><![CDATA[_tmo]]></c>-function with the last argument as
- <c><![CDATA[0]]></c> is therefore exactly the same thing as calling the
- function without the <c><![CDATA[_tmo]]></c> suffix.</p>
- <p>As with all other ei functions, you are <em>not</em> expected
- to put the socket in non blocking mode yourself in the program. Every
- use of non blocking mode is embedded inside the timeout
+ socket operations.</p>
+
+ <p>A time-out value of <c><![CDATA[0]]></c> (zero) means that time-outs are
+ disabled. Calling a <c><![CDATA[_tmo]]></c> function with the last
+ argument as <c><![CDATA[0]]></c> is therefore the same thing as calling
+ the function without the <c><![CDATA[_tmo]]></c> suffix.</p>
+
+ <p>As with all other functions starting with <c>ei_</c>,
+ you are <em>not</em> expected
+ to put the socket in non-blocking mode yourself in the program. Every
+ use of non-blocking mode is embedded inside the time-out
functions. The socket will always be back in blocking mode after
the operations are completed (regardless of the result). To
- avoid problems, leave the socket options alone. Ei will handle
+ avoid problems, leave the socket options alone. <c>ei</c> handles
any socket options that need modification.</p>
+
<p>In all other senses, the <c><![CDATA[_tmo]]></c> functions inherit all
the return values and the semantics from the functions without
the <c><![CDATA[_tmo]]></c> suffix.</p>
</section>
+
<funcs>
<func>
<name><ret>struct hostent</ret><nametext>*ei_gethostbyaddr(const char *addr, int len, int type)</nametext></name>
@@ -84,69 +93,88 @@
<name><ret>struct hostent</ret><nametext>*ei_gethostbyname_r(const char *name, struct hostent *hostp, char *buffer, int buflen, int *h_errnop)</nametext></name>
<fsummary>Name lookup functions.</fsummary>
<desc>
- <p>These are convenience functions for some common name lookup functions.</p>
+ <p>Convenience functions for some common name lookup functions.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_accept(ei_cnode *ec, int listensock, ErlConnect *conp)</nametext></name>
<fsummary>Accept a connection from another node.</fsummary>
<desc>
- <p>This function is used by a server process to accept a
+ <p>Used by a server process to accept a
connection from a client process.</p>
- <p><c><![CDATA[ec]]></c> is the C-node structure.</p>
- <p><c><![CDATA[listensock]]></c> is an open socket descriptor on which
- <c><![CDATA[listen()]]></c> has previously been called.</p>
- <p><c><![CDATA[conp]]></c> is a pointer to an <c><![CDATA[ErlConnect]]></c> struct,
- described as follows:</p>
- <code type="none"><![CDATA[
+ <list type="bulleted">
+ <item>
+ <p><c><![CDATA[ec]]></c> is the C-node structure.</p>
+ </item>
+ <item>
+ <p><c><![CDATA[listensock]]></c> is an open socket descriptor on
+ which <c><![CDATA[listen()]]></c> has previously been called.</p>
+ </item>
+ <item>
+ <p><c><![CDATA[conp]]></c> is a pointer to an
+ <c><![CDATA[ErlConnect]]></c> struct, described as follows:</p>
+ <code type="none"><![CDATA[
typedef struct {
char ipadr[4];
char nodename[MAXNODELEN];
} ErlConnect;
]]></code>
+ </item>
+ </list>
<p>On success, <c><![CDATA[conp]]></c> is filled in with the address and
node name of the connecting client and a file descriptor is
returned. On failure, <c><![CDATA[ERL_ERROR]]></c> is returned and
<c><![CDATA[erl_errno]]></c> is set to <c><![CDATA[EIO]]></c>.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_accept_tmo(ei_cnode *ec, int listensock, ErlConnect *conp, unsigned timeout_ms)</nametext></name>
- <fsummary>Accept a connection from another node with optional timeout.</fsummary>
+ <fsummary>Accept a connection from another node with optional
+ time-out.</fsummary>
<desc>
- <p>ei_accept with an optional timeout argument,
- see the description at the beginning of this document.</p>
+ <p>Equivalent to
+ <c>ei_accept</c> with an optional time-out argument,
+ see the description at the beginning of this manual page.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_connect(ei_cnode* ec, char *nodename)</nametext></name>
<name><ret>int</ret><nametext>ei_xconnect(ei_cnode* ec, Erl_IpAddr adr, char *alivename)</nametext></name>
- <fsummary>Establishe a connection to an Erlang node.</fsummary>
+ <fsummary>Establish a connection to an Erlang node.</fsummary>
<desc>
- <p>These functions set up a connection to an Erlang node.</p>
- <p><c><![CDATA[ei_xconnect()]]></c> requires the IP address of the remote
- host and the alive name of the remote node
- to be specified. <c><![CDATA[ei_connect()]]></c> provides an alternative
- interface, and determines the information from the node name
+ <p>Sets up a connection to an Erlang node.</p>
+ <p><c><![CDATA[ei_xconnect()]]></c> requires the IP address of the
+ remote host and the alive name of the remote node to be
+ specified. <c><![CDATA[ei_connect()]]></c> provides an alternative
+ interface and determines the information from the node name
provided.</p>
- <p><c><![CDATA[addr]]></c> is the 32-bit IP address of the remote host.</p>
- <p><c><![CDATA[alive]]></c> is the alivename of the remote node.</p>
- <p><c><![CDATA[node]]></c> is the name of the remote node.</p>
+ <list type="bulleted">
+ <item><c><![CDATA[addr]]></c> is the 32-bit IP address of the remote
+ host.</item>
+ <item><c><![CDATA[alive]]></c> is the alivename of the remote node.
+ </item>
+ <item><c><![CDATA[node]]></c> is the name of the remote node.</item>
+ </list>
<p>These functions return an open file descriptor on success, or
- a negative value indicating that an error occurred --- in
- which case they will set <c><![CDATA[erl_errno]]></c> to one of:</p>
+ a negative value indicating that an error occurred. In the latter
+ case they set <c><![CDATA[erl_errno]]></c> to one of the
+ following:</p>
<taglist>
<tag><c><![CDATA[EHOSTUNREACH]]></c></tag>
- <item>The remote host <c><![CDATA[node]]></c> is unreachable</item>
+ <item>The remote host <c><![CDATA[node]]></c> is unreachable.</item>
<tag><c><![CDATA[ENOMEM]]></c></tag>
- <item>No more memory available.</item>
+ <item>No more memory is available.</item>
<tag><c><![CDATA[EIO]]></c></tag>
<item>I/O error.</item>
</taglist>
- <p>Additionally, <c><![CDATA[errno]]></c> values from
- <c><![CDATA[socket]]></c><em>(2)</em> and <c><![CDATA[connect]]></c><em>(2)</em>
+ <p>Also, <c><![CDATA[errno]]></c> values from
+ <c><![CDATA[socket]]></c><em>(2)</em> and
+ <c><![CDATA[connect]]></c><em>(2)</em>
system calls may be propagated into <c><![CDATA[erl_errno]]></c>.</p>
- <p>Example:</p>
+ <p><em>Example:</em></p>
<code type="none"><![CDATA[
#define NODE "[email protected]"
#define ALIVE "madonna"
@@ -162,42 +190,62 @@ fd = ei_xconnect(&ec, &addr, ALIVE);
]]></code>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_connect_init(ei_cnode* ec, const char* this_node_name, const char *cookie, short creation)</nametext></name>
<name><ret>int</ret><nametext>ei_connect_xinit(ei_cnode* ec, const char *thishostname, const char *thisalivename, const char *thisnodename, Erl_IpAddr thisipaddr, const char *cookie, short creation)</nametext></name>
<fsummary>Initialize for a connection.</fsummary>
<desc>
- <p>These function initializes the <c><![CDATA[ec]]></c> structure, to
+ <p>Initializes the <c><![CDATA[ec]]></c> structure, to
identify the node name and cookie of the server. One of them
- has to be called before other functions that works on the
- type <c><![CDATA[ei_cnode]]></c> or a file descriptor associated with a
- connection to another node are used.</p>
- <p><c><![CDATA[ec]]></c> is a structure containing information about the
- C-node. It is used in other <c><![CDATA[ei]]></c> functions for
- connecting and receiving data.</p>
- <p><c><![CDATA[this_node_name]]></c> is the registered name of the process
- (the name before '@').</p>
- <p><c><![CDATA[cookie]]></c> is the cookie for the node.</p>
- <p><c><![CDATA[creation]]></c> identifies a specific instance of a C
- node. It can help prevent the node from receiving messages
- sent to an earlier process with the same registered name.</p>
- <p><c><![CDATA[thishostname]]></c> is the name of the machine we're running
- on. If long names are to be used, it should be fully
- qualified (i.e. <c><![CDATA[durin.erix.ericsson.se]]></c> instead of
- <c><![CDATA[durin]]></c>).</p>
- <p><c><![CDATA[thisalivename]]></c> is the registered name of the process.</p>
- <p><c><![CDATA[thisnodename]]></c> is the full name of the node,
- i.e. <c><![CDATA[einode@durin]]></c>.</p>
- <p><c><![CDATA[thispaddr]]></c> if the IP address of the host.</p>
- <p>A C node acting as a server will be assigned a creation
+ must be called before other functions that works on the
+ <c><![CDATA[ei_cnode]]></c> type or a file descriptor associated with
+ a connection to another node is used.</p>
+ <list type="bulleted">
+ <item>
+ <p><c><![CDATA[ec]]></c> is a structure containing information about
+ the C-node. It is used in other <c><![CDATA[ei]]></c> functions
+ for connecting and receiving data.</p>
+ </item>
+ <item>
+ <p><c><![CDATA[this_node_name]]></c> is the registered name of the
+ process (the name before '@').</p>
+ </item>
+ <item>
+ <p><c><![CDATA[cookie]]></c> is the cookie for the node.</p>
+ </item>
+ <item>
+ <p><c><![CDATA[creation]]></c> identifies a specific instance of a
+ C-node. It can help prevent the node from receiving messages
+ sent to an earlier process with the same registered name.</p>
+ </item>
+ <item>
+ <p><c><![CDATA[thishostname]]></c> is the name of the machine we are
+ running on. If long names are to be used, they are to be fully
+ qualified (that is, <c><![CDATA[durin.erix.ericsson.se]]></c>
+ instead of <c><![CDATA[durin]]></c>).</p>
+ </item>
+ <item>
+ <p><c><![CDATA[thisalivename]]></c> is the registered name of the
+ process.</p>
+ </item>
+ <item>
+ <p><c><![CDATA[thisnodename]]></c> is the full name of the node,
+ that is, <c><![CDATA[einode@durin]]></c>.</p>
+ </item>
+ <item>
+ <p><c><![CDATA[thispaddr]]></c> if the IP address of the host.</p>
+ </item>
+ </list>
+ <p>A C-node acting as a server is assigned a creation
number when it calls <c><![CDATA[ei_publish()]]></c>.</p>
- <p>A connection is closed by simply closing the socket. Refer
- to system documentation to close the socket gracefully (when
- there are outgoing packets before close).</p>
- <p>This function return a negative value indicating that an error
+ <p>A connection is closed by simply closing the socket.
+ For information about how to close the socket gracefully (when
+ there are outgoing packets before close), see the relevant system
+ documentation.</p>
+ <p>These functions return a negative value indicating that an error
occurred.</p>
- <p>Example 1:
- </p>
+ <p><em>Example 1:</em></p>
<code type="none"><![CDATA[
int n = 0;
struct in_addr addr;
@@ -214,8 +262,7 @@ if (ei_connect_xinit(&ec,
exit(-1);
}
]]></code>
- <p>Example 2:
- </p>
+ <p><em>Example 2:</em></p>
<code type="none"><![CDATA[
if (ei_connect_init(&ec, "madonna", "cookie...", n++) < 0) {
fprintf(stderr,"ERROR when initializing: %d",erl_errno);
@@ -224,87 +271,122 @@ if (ei_connect_init(&ec, "madonna", "cookie...", n++) < 0) {
]]></code>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_connect_tmo(ei_cnode* ec, char *nodename, unsigned timeout_ms)</nametext></name>
<name><ret>int</ret><nametext>ei_xconnect_tmo(ei_cnode* ec, Erl_IpAddr adr, char *alivename, unsigned timeout_ms)</nametext></name>
- <fsummary>Establish a connection to an Erlang node with optional timeout.</fsummary>
+ <fsummary>Establish a connection to an Erlang node with optional
+ time-out.</fsummary>
<desc>
- <p>ei_connect and ei_xconnect with an optional timeout argument,
- see the description at the beginning of this document.</p>
+ <p>Equivalent to
+ <c>ei_connect</c> and <c>ei_xconnect</c> with an optional time-out
+ argument, see the description at the beginning of this manual
+ page.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_get_tracelevel(void)</nametext></name>
<name><ret>void</ret><nametext>ei_set_tracelevel(int level)</nametext></name>
<fsummary>Get and set functions for tracing.</fsummary>
<desc>
- <p>These functions are used to set tracing on the distribution. The levels are different verbosity levels. A higher level means more information.
- See also Debug Information and <c><![CDATA[EI_TRACELEVEL]]></c> below. </p>
- <p> <c><![CDATA[ei_set_tracelevel]]></c> and <c><![CDATA[ei_get_tracelevel]]></c> are not thread safe. </p>
+ <p>Used to set tracing on the distribution. The levels are different
+ verbosity levels. A higher level means more information. See also
+ section <seealso marker="debug_information">
+ Debug Information</seealso>.</p>
+ <p>These functions are not thread safe.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_publish(ei_cnode *ec, int port)</nametext></name>
<fsummary>Publish a node name.</fsummary>
<desc>
- <p>These functions are used by a server process to register
+ <p>Used by a server process to register
with the local name server <em>epmd</em>, thereby allowing
other processes to send messages by using the registered name.
Before calling either of these functions, the process should
- have called <c><![CDATA[bind()]]></c> and <c><![CDATA[listen()]]></c> on an open socket.</p>
- <p><c><![CDATA[ec]]></c> is the C-node structure.</p>
- <p><c><![CDATA[port]]></c> is the local name to register, and should be the
- same as the port number that was previously bound to the socket.</p>
- <p><c><![CDATA[addr]]></c> is the 32-bit IP address of the local host.</p>
- <p>To unregister with epmd, simply close the returned
- descriptor. Do not use <c><![CDATA[ei_unpublish()]]></c>, which is deprecated anyway.</p>
- <p>On success, the functions return a descriptor connecting the
- calling process to epmd. On failure, they return -1 and set
- <c><![CDATA[erl_errno]]></c> to <c><![CDATA[EIO]]></c>.</p>
- <p>Additionally, <c><![CDATA[errno]]></c> values from <c><![CDATA[socket]]></c><em>(2)</em>
- and <c><![CDATA[connect]]></c><em>(2)</em> system calls may be propagated
+ have called <c><![CDATA[bind()]]></c> and <c><![CDATA[listen()]]></c>
+ on an open socket.</p>
+ <list type="bulleted">
+ <item>
+ <p><c><![CDATA[ec]]></c> is the C-node structure.</p>
+ </item>
+ <item>
+ <p><c><![CDATA[port]]></c> is the local name to register, and is to
+ be the same as the port number that was previously bound to the
+ socket.</p>
+ </item>
+ <item>
+ <p><c><![CDATA[addr]]></c> is the 32-bit IP address of the local
+ host.</p>
+ </item>
+ </list>
+ <p>To unregister with EPMD, simply close the returned descriptor. Do
+ not use <c><![CDATA[ei_unpublish()]]></c>, which is deprecated
+ anyway.</p>
+ <p>On success, the function returns a descriptor connecting the
+ calling process to EPMD. On failure, <c>-1</c> is returned and
+ <c><![CDATA[erl_errno]]></c> is set to <c><![CDATA[EIO]]></c>.</p>
+ <p>Also, <c><![CDATA[errno]]></c> values from
+ <c><![CDATA[socket]]></c><em>(2)</em> and
+ <c><![CDATA[connect]]></c><em>(2)</em> system calls may be propagated
into <c><![CDATA[erl_errno]]></c>.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_publish_tmo(ei_cnode *ec, int port, unsigned timeout_ms)</nametext></name>
- <fsummary>Publish a node name with optional timeout.</fsummary>
+ <fsummary>Publish a node name with optional time-out.</fsummary>
<desc>
- <p>ei_publish with an optional timeout argument,
- see the description at the beginning of this document.</p>
+ <p>Equivalent to
+ <c>ei_publish</c> with an optional time-out argument,
+ see the description at the beginning of this manual page.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_receive(int fd, unsigned char* bufp, int bufsize)</nametext></name>
<fsummary>Receive a message.</fsummary>
+ <marker id="ei_receive"/>
<desc>
- <p>This function receives a message consisting of a sequence
+ <p>Receives a message consisting of a sequence
of bytes in the Erlang external format.</p>
- <p><c><![CDATA[fd]]></c> is an open descriptor to an Erlang connection. It
- is obtained from a previous <c><![CDATA[ei_connect]]></c> or
- <c><![CDATA[ei_accept]]></c>.</p>
- <p><c><![CDATA[bufp]]></c> is a buffer large enough to hold the expected
- message. </p>
- <p><c><![CDATA[bufsize]]></c> indicates the size of <c><![CDATA[bufp]]></c>.</p>
- <p>If a <em>tick</em> occurs, i.e., the Erlang node on the
+ <list type="bulleted">
+ <item>
+ <p><c><![CDATA[fd]]></c> is an open descriptor to an Erlang
+ connection. It is obtained from a previous
+ <c><![CDATA[ei_connect]]></c> or <c><![CDATA[ei_accept]]></c>.</p>
+ </item>
+ <item>
+ <p><c><![CDATA[bufp]]></c> is a buffer large enough to hold the
+ expected message.</p>
+ </item>
+ <item>
+ <p><c><![CDATA[bufsize]]></c> indicates the size of
+ <c><![CDATA[bufp]]></c>.</p>
+ </item>
+ </list>
+ <p>If a <em>tick</em> occurs, that is, the Erlang node on the
other end of the connection has polled this node to see if it
- is still alive, the function will return <c><![CDATA[ERL_TICK]]></c> and
- no message will be placed in the buffer. Also,
- <c><![CDATA[erl_errno]]></c> will be set to <c><![CDATA[EAGAIN]]></c>.</p>
+ is still alive, the function returns <c><![CDATA[ERL_TICK]]></c> and
+ no message is placed in the buffer. Also,
+ <c><![CDATA[erl_errno]]></c> is set to <c><![CDATA[EAGAIN]]></c>.</p>
<p>On success, the message is placed in the specified buffer
and the function returns the number of bytes actually read. On
- failure, the function returns <c><![CDATA[ERL_ERROR]]></c> and will set
- <c><![CDATA[erl_errno]]></c> to one of:</p>
+ failure, the function returns <c><![CDATA[ERL_ERROR]]></c> and sets
+ <c><![CDATA[erl_errno]]></c> to one of the following:</p>
<taglist>
<tag><c><![CDATA[EAGAIN]]></c></tag>
<item>Temporary error: Try again.</item>
<tag><c><![CDATA[EMSGSIZE]]></c></tag>
- <item>Buffer too small.</item>
+ <item>Buffer is too small.</item>
<tag><c><![CDATA[EIO]]></c></tag>
<item>I/O error.</item>
</taglist>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_receive_encoded(int fd, char **mbufp, int *bufsz, erlang_msg *msg, int *msglen)</nametext></name>
<fsummary>Obsolete function for receiving a message.</fsummary>
@@ -312,50 +394,63 @@ if (ei_connect_init(&ec, "madonna", "cookie...", n++) < 0) {
<p>This function is retained for compatibility with code
generated by the interface compiler and with code following
examples in the same application.</p>
- <p>In essence the function performs the same operation as
- <c><![CDATA[ei_xreceive_msg]]></c>, but instead of using an ei_x_buff, the
- function expects a pointer to a character pointer
- (<c><![CDATA[mbufp]]></c>), where the character pointer should point to a
- memory area allocated by <c><![CDATA[malloc]]></c>. The argument
- <c><![CDATA[bufsz]]></c> should be a pointer to an integer containing the
- exact size (in bytes) of the memory area. The function may
- reallocate the memory area and will in such cases put the new
- size in <c><![CDATA[*bufsz]]></c> and update <c><![CDATA[*mbufp]]></c>.</p>
- <p>Furthermore the function returns either ERL_TICK or the
- <c><![CDATA[msgtype]]></c> field of the <c><![CDATA[erlang_msg *msg]]></c>. The actual
- length of the message is put in <c><![CDATA[*msglen]]></c>. On error it
- will return a value <c><![CDATA[< 0]]></c>.</p>
- <p>It is recommended to use ei_xreceive_msg instead when
- possible, for the sake of readability. The function will
- however be retained in the interface for compatibility and
- will <em>not</em> be removed not be removed in future releases
- without notice.</p>
+ <p>In essence, the function performs the same operation as
+ <c><![CDATA[ei_xreceive_msg]]></c>, but instead of using an
+ <c>ei_x_buff</c>, the function expects a pointer to a character
+ pointer (<c><![CDATA[mbufp]]></c>), where the character pointer
+ is to point to a memory area allocated by <c><![CDATA[malloc]]></c>.
+ Argument <c><![CDATA[bufsz]]></c> is to be a pointer to an integer
+ containing the exact size (in bytes) of the memory area. The function
+ may reallocate the memory area and will in such cases put the new
+ size in <c><![CDATA[*bufsz]]></c> and update
+ <c><![CDATA[*mbufp]]></c>.</p>
+ <p>Returns either <c>ERL_TICK</c> or the
+ <c><![CDATA[msgtype]]></c> field of the
+ <c><![CDATA[erlang_msg *msg]]></c>. The length
+ of the message is put in <c><![CDATA[*msglen]]></c>. On error
+ a value <c><![CDATA[< 0]]></c> is returned.</p>
+ <p>It is recommended to use <c>ei_xreceive_msg</c> instead when
+ possible, for the sake of readability. However, the function will
+ be retained in the interface for compatibility and
+ will <em>not</em> be removed in future releases without prior
+ notice.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_receive_encoded_tmo(int fd, char **mbufp, int *bufsz, erlang_msg *msg, int *msglen, unsigned timeout_ms)</nametext></name>
- <fsummary>Obsolete function for receiving a message with timeout.</fsummary>
+ <fsummary>Obsolete function for receiving a message with time-out.
+ </fsummary>
<desc>
- <p>ei_receive_encoded with an optional timeout argument,
- see the description at the beginning of this document.</p>
+ <p>Equivalent to
+ <c>ei_receive_encoded</c> with an optional time-out argument,
+ see the description at the beginning of this manual page.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_receive_msg(int fd, erlang_msg* msg, ei_x_buff* x)</nametext></name>
<name><ret>int</ret><nametext>ei_xreceive_msg(int fd, erlang_msg* msg, ei_x_buff* x)</nametext></name>
<fsummary>Receive a message.</fsummary>
+ <marker id="ei_receive_msg"/>
<desc>
- <p>These functions receives a message to the buffer in
- <c><![CDATA[x]]></c>. <c><![CDATA[ei_xreceive_msg]]></c> allows the buffer in
- <c><![CDATA[x]]></c> to grow, but <c><![CDATA[ei_receive_msg]]></c> fails if the
- message is bigger than the preallocated buffer in <c><![CDATA[x]]></c>.</p>
- <p><c><![CDATA[fd]]></c> is an open descriptor to an Erlang connection.</p>
- <p><c><![CDATA[msg]]></c> is a pointer to an <c><![CDATA[erlang_msg]]></c> structure
- and contains information on the message received.</p>
- <p><c><![CDATA[x]]></c> is buffer obtained from <c><![CDATA[ei_x_new]]></c>.</p>
- <p>On success, the function returns <c><![CDATA[ERL_MSG]]></c> and the
- <c><![CDATA[msg]]></c> struct will be initialized. <c><![CDATA[erlang_msg]]></c>
- is defined as follows:</p>
+ <p>Receives a message to the buffer in <c><![CDATA[x]]></c>.
+ <c><![CDATA[ei_xreceive_msg]]></c> allows the buffer in
+ <c><![CDATA[x]]></c> to grow, but <c><![CDATA[ei_receive_msg]]></c>
+ fails if the message is larger than the pre-allocated buffer in
+ <c><![CDATA[x]]></c>.</p>
+ <list type="bulleted">
+ <item><c><![CDATA[fd]]></c> is an open descriptor to an Erlang
+ connection.</item>
+ <item><c><![CDATA[msg]]></c> is a pointer to an
+ <c><![CDATA[erlang_msg]]></c> structure
+ and contains information on the message received.</item>
+ <item><c><![CDATA[x]]></c> is buffer obtained from
+ <c><![CDATA[ei_x_new]]></c>.</item>
+ </list>
+ <p>On success, the functions return <c><![CDATA[ERL_MSG]]></c> and the
+ <c><![CDATA[msg]]></c> struct is initialized.
+ <c><![CDATA[erlang_msg]]></c> is defined as follows:</p>
<code type="none"><![CDATA[
typedef struct {
long msgtype;
@@ -366,58 +461,82 @@ typedef struct {
erlang_trace token;
} erlang_msg;
]]></code>
- <p><c><![CDATA[msgtype]]></c> identifies the type of message, and is one of
- <c><![CDATA[ERL_SEND]]></c>, <c><![CDATA[ERL_REG_SEND]]></c>, <c><![CDATA[ERL_LINK]]></c>,
- <c><![CDATA[ERL_UNLINK]]></c> and <c><![CDATA[ERL_EXIT]]></c>.</p>
- <p>If <c><![CDATA[msgtype]]></c> is <c><![CDATA[ERL_SEND]]></c> this indicates that an
- ordinary send operation has taken place, and <c><![CDATA[msg->to]]></c>
- contains the Pid of the recipient (the C-node). If
- <c><![CDATA[type]]></c> is <c><![CDATA[ERL_REG_SEND]]></c> then a registered send
- operation took place, and <c><![CDATA[msg->from]]></c> contains the Pid
- of the sender.</p>
- <p>If <c><![CDATA[msgtype]]></c> is <c><![CDATA[ERL_LINK]]></c> or <c><![CDATA[ERL_UNLINK]]></c>, then
- <c><![CDATA[msg->to]]></c> and <c><![CDATA[msg->from]]></c> contain the pids of the
- sender and recipient of the link or unlink.</p>
- <p>If <c><![CDATA[msgtype]]></c> is <c><![CDATA[ERL_EXIT]]></c>, then this indicates that
- a link has been broken. In this case, <c><![CDATA[msg->to]]></c> and
- <c><![CDATA[msg->from]]></c> contain the pids of the linked processes.</p>
- <p>The return value is the same as for <c><![CDATA[ei_receive]]></c>, see
- above.</p>
+ <p><c><![CDATA[msgtype]]></c> identifies the type of message, and is
+ one of the following:</p>
+ <taglist>
+ <tag><c><![CDATA[ERL_SEND]]></c></tag>
+ <item>
+ <p>Indicates that an ordinary send operation has occurred.
+ <c><![CDATA[msg->to]]></c> contains the pid of the recipient (the
+ C-node).</p>
+ </item>
+ <tag><c><![CDATA[ERL_REG_SEND]]></c></tag>
+ <item>
+ <p>A registered send operation occurred.
+ <c><![CDATA[msg->from]]></c> contains the pid of the sender.</p>
+ </item>
+ <tag><c><![CDATA[ERL_LINK]]></c> or
+ <c><![CDATA[ERL_UNLINK]]></c></tag>
+ <item>
+ <p><c><![CDATA[msg->to]]></c> and
+ <c><![CDATA[msg->from]]></c> contain the pids of the
+ sender and recipient of the link or unlink.</p>
+ </item>
+ <tag><c><![CDATA[ERL_EXIT]]></c></tag>
+ <item>
+ <p>Indicates a broken link. <c><![CDATA[msg->to]]></c> and
+ <c><![CDATA[msg->from]]></c> contain the pids of the linked
+ processes.</p>
+ </item>
+ </taglist>
+ <p>The return value is the same as for
+ <seealso marker="#ei_receive"><c>ei_receive</c></seealso>.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_receive_msg_tmo(int fd, erlang_msg* msg, ei_x_buff* x, unsigned imeout_ms)</nametext></name>
<name><ret>int</ret><nametext>ei_xreceive_msg_tmo(int fd, erlang_msg* msg, ei_x_buff* x, unsigned timeout_ms)</nametext></name>
- <fsummary>Receive a message with optional timeout.</fsummary>
+ <fsummary>Receive a message with optional time-out.</fsummary>
<desc>
- <p>ei_receive_msg and ei_xreceive_msg with an optional timeout argument,
- see the description at the beginning of this document.</p>
+ <p>Equivalent to <c>ei_receive_msg</c> and <c>ei_xreceive_msg</c>
+ with an optional time-out argument,
+ see the description at the beginning of this manual page.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_receive_tmo(int fd, unsigned char* bufp, int bufsize, unsigned timeout_ms)</nametext></name>
- <fsummary>Receive a message with optional timeout.</fsummary>
+ <fsummary>Receive a message with optional time-out.</fsummary>
<desc>
- <p>ei_receive with an optional timeout argument,
- see the description at the beginning of this document.</p>
+ <p>Equivalent to
+ <c>ei_receive</c> with an optional time-out argument,
+ see the description at the beginning of this manual page.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_reg_send(ei_cnode* ec, int fd, char* server_name, char* buf, int len)</nametext></name>
<fsummary>Send a message to a registered name.</fsummary>
<desc>
- <p>This function sends an Erlang term to a registered process.
- </p>
- <p>This function sends an Erlang term to a process.</p>
- <p><c><![CDATA[fd]]></c> is an open descriptor to an Erlang connection.</p>
- <p><c><![CDATA[server_name]]></c> is the registered name of the intended
- recipient.</p>
- <p><c><![CDATA[buf]]></c> is the buffer containing the term in binary
- format.</p>
- <p><c><![CDATA[len]]></c> is the length of the message in bytes.</p>
- <p>The function returns 0 if successful, otherwise -1, in the
- latter case it will set <c><![CDATA[erl_errno]]></c> to <c><![CDATA[EIO]]></c>.</p>
- <p>Example, send the atom "ok" to the process "worker":</p>
+ <p>Sends an Erlang term to a registered process.</p>
+ <list type="bulleted">
+ <item>
+ <p><c><![CDATA[fd]]></c> is an open descriptor to an Erlang
+ connection.</p>
+ </item>
+ <item><c><![CDATA[server_name]]></c> is the registered name of the
+ intended recipient.</item>
+ <item><c><![CDATA[buf]]></c> is the buffer containing the term in
+ binary format.</item>
+ <item><c><![CDATA[len]]></c> is the length of the message in bytes.
+ </item>
+ </list>
+ <p>Returns <c>0</c> if successful, otherwise <c>-1</c>. In
+ the latter case it sets <c><![CDATA[erl_errno]]></c> to
+ <c><![CDATA[EIO]]></c>.</p>
+ <p><em>Example:</em></p>
+ <p>Send the atom "ok" to the process "worker":</p>
<code type="none"><![CDATA[
ei_x_buff x;
ei_x_new_with_version(&x);
@@ -427,64 +546,98 @@ if (ei_reg_send(&ec, fd, x.buff, x.index) < 0)
]]></code>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_reg_send_tmo(ei_cnode* ec, int fd, char* server_name, char* buf, int len, unsigned timeout_ms)</nametext></name>
- <fsummary>Send a message to a registered name with optional timeout.</fsummary>
+ <fsummary>Send a message to a registered name with optional time-out
+ </fsummary>
<desc>
- <p>ei_reg_send with an optional timeout argument,
- see the description at the beginning of this document.</p>
+ <p>Equivalent to
+ <c>ei_reg_send</c> with an optional time-out argument,
+ see the description at the beginning of this manual page.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_rpc(ei_cnode *ec, int fd, char *mod, char *fun, const char *argbuf, int argbuflen, ei_x_buff *x)</nametext></name>
<name><ret>int</ret><nametext>ei_rpc_to(ei_cnode *ec, int fd, char *mod, char *fun, const char *argbuf, int argbuflen)</nametext></name>
<name><ret>int</ret><nametext>ei_rpc_from(ei_cnode *ec, int fd, int timeout, erlang_msg *msg, ei_x_buff *x)</nametext></name>
<fsummary>Remote Procedure Call from C to Erlang.</fsummary>
<desc>
- <p>These functions support calling Erlang functions on remote nodes.
- <c><![CDATA[ei_rpc_to()]]></c> sends an rpc request to a remote node and
- <c><![CDATA[ei_rpc_from()]]></c> receives the results of such a call.
- <c><![CDATA[ei_rpc()]]></c> combines the functionality of these two functions
- by sending an rpc request and waiting for the results. See also
- <c><![CDATA[rpc:call/4]]></c>. </p>
- <p><c><![CDATA[ec]]></c> is the C-node structure previously initiated by a
- call to <c><![CDATA[ei_connect_init()]]></c> or
- <c><![CDATA[ei_connect_xinit()]]></c></p>
- <p><c><![CDATA[fd]]></c> is an open descriptor to an Erlang connection.</p>
- <p><c><![CDATA[timeout]]></c> is the maximum time (in ms) to wait for
- results. Specify <c><![CDATA[ERL_NO_TIMEOUT]]></c> to wait forever.
- <c><![CDATA[ei_rpc()]]></c> will wait infinitely for the answer,
- i.e. the call will never time out.</p>
- <p><c><![CDATA[mod]]></c> is the name of the module containing the function
- to be run on the remote node.</p>
- <p><c><![CDATA[fun]]></c> is the name of the function to run.</p>
- <p><c><![CDATA[argbuf]]></c> is a pointer to a buffer with an encoded
- Erlang list, without a version magic number, containing the
- arguments to be passed to the function.</p>
- <p><c><![CDATA[argbuflen]]></c> is the length of the buffer containing the
- encoded Erlang list.</p>
- <p><c><![CDATA[msg]]></c> structure of type <c><![CDATA[erlang_msg]]></c> and contains
- information on the message received. See <c><![CDATA[ei_receive_msg()]]></c>
- for a description of the <c><![CDATA[erlang_msg]]></c> format.</p>
- <p><c><![CDATA[x]]></c> points to the dynamic buffer that receives the
- result. For for <c><![CDATA[ei_rpc()]]></c> this will be the result
- without the version magic number. For <c><![CDATA[ei_rpc_from()]]></c>
- the result will return a version magic number and a 2-tuple
- <c><![CDATA[{rex,Reply}]]></c>.</p>
- <p><c><![CDATA[ei_rpc()]]></c> returns the number of bytes in the result
- on success and -1 on failure. <c><![CDATA[ei_rpc_from()]]></c> returns
- number of bytes or one of <c><![CDATA[ERL_TICK]]></c>, <c><![CDATA[ERL_TIMEOUT]]></c>
- and <c><![CDATA[ERL_ERROR]]></c> otherwise. When failing,
- all three functions set <c><![CDATA[erl_errno]]></c> to one of:</p>
+ <p>Supports calling Erlang functions on remote nodes.
+ <c><![CDATA[ei_rpc_to()]]></c> sends an RPC request to a remote node
+ and <c><![CDATA[ei_rpc_from()]]></c> receives the results of such a
+ call. <c><![CDATA[ei_rpc()]]></c> combines the functionality of these
+ two functions by sending an RPC request and waiting for the results.
+ See also <seealso marker="kernel:rpc#call/4">
+ <c>rpc:call/4</c></seealso> in <c>Kernel</c>.</p>
+ <list type="bulleted">
+ <item>
+ <p><c><![CDATA[ec]]></c> is the C-node structure previously
+ initiated by a call to <c><![CDATA[ei_connect_init()]]></c> or
+ <c><![CDATA[ei_connect_xinit()]]></c>.</p>
+ </item>
+ <item>
+ <p><c><![CDATA[fd]]></c> is an open descriptor to an Erlang
+ connection.</p>
+ </item>
+ <item>
+ <p><c><![CDATA[timeout]]></c> is the maximum time (in milliseconds)
+ to wait for results. Specify <c><![CDATA[ERL_NO_TIMEOUT]]></c> to
+ wait forever.
+ <c><![CDATA[ei_rpc()]]></c> waits infinitely for the answer,
+ that is, the call will never time out.</p>
+ </item>
+ <item>
+ <p><c><![CDATA[mod]]></c> is the name of the module containing the
+ function to be run on the remote node.</p>
+ </item>
+ <item>
+ <p><c><![CDATA[fun]]></c> is the name of the function to run.</p>
+ </item>
+ <item>
+ <p><c><![CDATA[argbuf]]></c> is a pointer to a buffer with an
+ encoded Erlang list, without a version magic number, containing
+ the arguments to be passed to the function.</p>
+ </item>
+ <item>
+ <p><c><![CDATA[argbuflen]]></c> is the length of the buffer
+ containing the encoded Erlang list.</p>
+ </item>
+ <item>
+ <p><c><![CDATA[msg]]></c> is structure of type
+ <c><![CDATA[erlang_msg]]></c> and contains information on the
+ message
+ received. For a description of the <c><![CDATA[erlang_msg]]></c>
+ format, see <seealso marker="#ei_receive_msg">
+ <c>ei_receive_msg</c></seealso>.</p>
+ </item>
+ <item>
+ <p><c><![CDATA[x]]></c> points to the dynamic buffer that receives
+ the result. For <c><![CDATA[ei_rpc()]]></c> this is the result
+ without the version magic number. For
+ <c><![CDATA[ei_rpc_from()]]></c> the result returns a version
+ magic number and a 2-tuple <c><![CDATA[{rex,Reply}]]></c>.</p>
+ </item>
+ </list>
+ <p><c><![CDATA[ei_rpc()]]></c> returns the number of bytes in the
+ result on success and <c>-1</c> on failure.
+ <c><![CDATA[ei_rpc_from()]]></c> returns the
+ number of bytes, otherwise one of <c><![CDATA[ERL_TICK]]></c>,
+ <c><![CDATA[ERL_TIMEOUT]]></c>,
+ and <c><![CDATA[ERL_ERROR]]></c>. When failing, all three
+ functions set <c><![CDATA[erl_errno]]></c> to one of the
+ following:</p>
<taglist>
<tag><c><![CDATA[EIO]]></c></tag>
<item>I/O error.</item>
<tag><c><![CDATA[ETIMEDOUT]]></c></tag>
- <item>Timeout expired.</item>
+ <item>Time-out expired.</item>
<tag><c><![CDATA[EAGAIN]]></c></tag>
<item>Temporary error: Try again.</item>
</taglist>
- <p>Example, check to see if an erlang process is alive:</p>
+ <p><em>Example:</em></p>
+ <p>Check to see if an Erlang process is alive:</p>
<code type="none"><![CDATA[
int index = 0, is_alive;
ei_x_buff args, result;
@@ -505,156 +658,187 @@ if (ei_decode_version(result.buff, &index) < 0
]]></code>
</desc>
</func>
+
<func>
<name><ret>erlang_pid *</ret><nametext>ei_self(ei_cnode *ec)</nametext></name>
- <fsummary>Retrieve the Pid of the C-node.</fsummary>
+ <fsummary>Retrieve the pid of the C-node.</fsummary>
<desc>
- <p>This function retrieves the Pid of the C-node. Every C-node
- has a (pseudo) pid used in <c><![CDATA[ei_send_reg]]></c>, <c><![CDATA[ei_rpc]]></c>
+ <p>Retrieves the pid of the C-node. Every C-node
+ has a (pseudo) pid used in <c><![CDATA[ei_send_reg]]></c>,
+ <c><![CDATA[ei_rpc]]></c>,
and others. This is contained in a field in the <c><![CDATA[ec]]></c>
structure. It will be safe for a long time to fetch this
field directly from the <c><![CDATA[ei_cnode]]></c> structure.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_send(int fd, erlang_pid* to, char* buf, int len)</nametext></name>
<fsummary>Send a message.</fsummary>
<desc>
- <p>This function sends an Erlang term to a process.</p>
- <p><c><![CDATA[fd]]></c> is an open descriptor to an Erlang connection.</p>
- <p><c><![CDATA[to]]></c> is the Pid of the intended recipient of the
- message.</p>
- <p><c><![CDATA[buf]]></c> is the buffer containing the term in binary
- format.</p>
- <p><c><![CDATA[len]]></c> is the length of the message in bytes.</p>
- <p>The function returns 0 if successful, otherwise -1, in the
- latter case it will set <c><![CDATA[erl_errno]]></c> to <c><![CDATA[EIO]]></c>.</p>
+ <p>Sends an Erlang term to a process.</p>
+ <list type="bulleted">
+ <item><c><![CDATA[fd]]></c> is an open descriptor to an Erlang
+ connection.</item>
+ <item><c><![CDATA[to]]></c> is the pid of the intended recipient of
+ the message.</item>
+ <item><c><![CDATA[buf]]></c> is the buffer containing the term in
+ binary format.</item>
+ <item><c><![CDATA[len]]></c> is the length of the message in bytes.
+ </item>
+ </list>
+ <p>Returns <c>0</c> if successful, otherwise <c>-1</c>. In
+ the latter case it sets <c><![CDATA[erl_errno]]></c> to
+ <c><![CDATA[EIO]]></c>.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_send_encoded(int fd, erlang_pid* to, char* buf, int len)</nametext></name>
<fsummary>Obsolete function to send a message.</fsummary>
<desc>
- <p>Works exactly as ei_send, the alternative name retained for
+ <p>Works exactly as <c>ei_send</c>, the alternative name is retained for
backward compatibility. The function will <em>not</em> be
- removed without notice.</p>
+ removed without prior notice.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_send_encoded_tmo(int fd, erlang_pid* to, char* buf, int len, unsigned timeout_ms)</nametext></name>
- <fsummary>Obsolete function to send a message with optional timeout.</fsummary>
+ <fsummary>Obsolete function to send a message with optional time-out.
+ </fsummary>
<desc>
- <p>ei_send_encoded with an optional timeout argument,
- see the description at the beginning of this document.</p>
+ <p>Equivalent to
+ <c>ei_send_encoded</c> with an optional time-out argument,
+ see the description at the beginning of this manual page.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_send_reg_encoded(int fd, const erlang_pid *from, const char *to, const char *buf, int len)</nametext></name>
- <fsummary>Obsolete function to send a message to a registered name.</fsummary>
+ <fsummary>Obsolete function to send a message to a registered name.
+ </fsummary>
<desc>
<p>This function is retained for compatibility with code
generated by the interface compiler and with code following
examples in the same application.</p>
<p>The function works as <c><![CDATA[ei_reg_send]]></c> with one
- exception. Instead of taking the <c><![CDATA[ei_cnode]]></c> as a first
- argument, it takes a second argument, an <c><![CDATA[erlang_pid]]></c>
- which should be the process identifier of the sending process
- (in the erlang distribution protocol). </p>
+ exception. Instead of taking <c><![CDATA[ei_cnode]]></c> as first
+ argument, it takes a second argument, an
+ <c><![CDATA[erlang_pid]]></c>,
+ which is to be the process identifier of the sending process
+ (in the Erlang distribution protocol).</p>
<p>A suitable <c><![CDATA[erlang_pid]]></c> can be constructed from the
- <c><![CDATA[ei_cnode]]></c> structure by the following example code:</p>
+ <c><![CDATA[ei_cnode]]></c> structure by the following example
+ code:</p>
<code type="none"><![CDATA[
- ei_cnode ec;
- erlang_pid *self;
- int fd; /* the connection fd */
- ...
- self = ei_self(&ec);
- self->num = fd;
+ei_cnode ec;
+erlang_pid *self;
+int fd; /* the connection fd */
+...
+self = ei_self(&ec);
+self->num = fd;
]]></code>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_send_reg_encoded_tmo(int fd, const erlang_pid *from, const char *to, const char *buf, int len)</nametext></name>
- <fsummary>Obsolete function to send a message to a registered name with timeout.</fsummary>
+ <fsummary>Obsolete function to send a message to a registered name with
+ time-out.</fsummary>
<desc>
- <p>ei_send_reg_encoded with an optional timeout argument,
- see the description at the beginning of this document.</p>
+ <p>Equivalent to
+ <c>ei_send_reg_encoded</c> with an optional time-out argument,
+ see the description at the beginning of this manual page.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_send_tmo(int fd, erlang_pid* to, char* buf, int len, unsigned timeout_ms)</nametext></name>
- <fsummary>Send a message with optional timeout.</fsummary>
+ <fsummary>Send a message with optional time-out.</fsummary>
<desc>
- <p>ei_send with an optional timeout argument,
- see the description at the beginning of this document.</p>
+ <p>Equivalent to
+ <c>ei_send</c> with an optional time-out argument,
+ see the description at the beginning of this manual page.</p>
</desc>
</func>
+
<func>
<name><ret>const char *</ret><nametext>ei_thisnodename(ei_cnode *ec)</nametext></name>
<name><ret>const char *</ret><nametext>ei_thishostname(ei_cnode *ec)</nametext></name>
<name><ret>const char *</ret><nametext>ei_thisalivename(ei_cnode *ec)</nametext></name>
<fsummary>Retrieve some values.</fsummary>
<desc>
- <p>These functions can be used to retrieve information about
- the C Node. These values are initially set with
- <c><![CDATA[ei_connect_init()]]></c> or <c><![CDATA[ei_connect_xinit()]]></c>.</p>
- <p>They simply fetches the appropriate field from the <c><![CDATA[ec]]></c>
+ <p>Can be used to retrieve information about
+ the C-node. These values are initially set with
+ <c><![CDATA[ei_connect_init()]]></c> or
+ <c><![CDATA[ei_connect_xinit()]]></c>.</p>
+ <p>These function simply fetch the appropriate field from the
+ <c><![CDATA[ec]]></c>
structure. Read the field directly will probably be safe for
a long time, so these functions are not really needed.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_unpublish(ei_cnode *ec)</nametext></name>
<fsummary>Forcefully unpublish a node name.</fsummary>
<desc>
- <p>This function can be called by a process to unregister a
- specified node from epmd on the localhost. This is however usually not
- allowed, unless epmd was started with the -relaxed_command_check
- flag, which it normally isn't.</p>
-
- <p>To unregister a node you have published, you should
+ <p>Can be called by a process to unregister a
+ specified node from EPMD on the local host. This is, however, usually
+ not allowed, unless EPMD was started with flag
+ <c>-relaxed_command_check</c>, which it normally is not.</p>
+ <p>To unregister a node you have published, you should
close the descriptor that was returned by
<c><![CDATA[ei_publish()]]></c>.</p>
-
<warning>
<p>This function is deprecated and will be removed in a future
release.</p>
</warning>
- <p><c><![CDATA[ec]]></c> is the node structure of the node to unregister.</p>
- <p>If the node was successfully unregistered from epmd, the
- function returns 0. Otherwise, it returns -1 and sets
- <c><![CDATA[erl_errno]]></c> is to <c><![CDATA[EIO]]></c>.</p>
+ <p><c><![CDATA[ec]]></c> is the node structure of the node to
+ unregister.</p>
+ <p>If the node was successfully unregistered from EPMD, the
+ function returns <c>0</c>. Otherwise, <c>-1</c> is returned and
+ <c><![CDATA[erl_errno]]></c> is set to <c><![CDATA[EIO]]></c>.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_unpublish_tmo(ei_cnode *ec, unsigned timeout_ms)</nametext></name>
- <fsummary>Unpublish a node name with optional timeout.</fsummary>
+ <fsummary>Unpublish a node name with optional time-out.</fsummary>
<desc>
- <p>ei_unpublish with an optional timeout argument,
- see the description at the beginning of this document.</p>
+ <p>Equivalent to
+ <c>ei_unpublish</c> with an optional time-out argument,
+ see the description at the beginning of this manual page.</p>
</desc>
</func>
- </funcs>
+ </funcs>
<section>
+ <marker id="debug_information"></marker>
<title>Debug Information</title>
<p>If a connection attempt fails, the following can be checked:</p>
+
<list type="bulleted">
- <item><c><![CDATA[erl_errno]]></c></item>
- <item>that the right cookie was used</item>
- <item>that <em>epmd</em> is running</item>
- <item>the remote Erlang node on the other side is running the
- same version of Erlang as the <c><![CDATA[ei]]></c>
- library.</item>
- <item>the environment variable <c><![CDATA[ERL_EPMD_PORT]]></c>
- is set correctly.</item>
+ <item><c><![CDATA[erl_errno]]></c>.</item>
+ <item>That the correct cookie was used</item>
+ <item>That EPMD is running</item>
+ <item>That the remote Erlang node on the other side is running the
+ same version of Erlang as the <c><![CDATA[ei]]></c> library</item>
+ <item>That environment variable <c><![CDATA[ERL_EPMD_PORT]]></c>
+ is set correctly</item>
</list>
- <p>The connection attempt can be traced by setting a tracelevel by either using
- <c><![CDATA[ei_set_tracelevel]]></c> or by setting the environment variable <c><![CDATA[EI_TRACELEVEL]]></c>.
- The different tracelevels has the following messages:</p>
+
+ <p>The connection attempt can be traced by setting a trace level by either
+ using <c><![CDATA[ei_set_tracelevel]]></c> or by setting environment
+ variable <c><![CDATA[EI_TRACELEVEL]]></c>.
+ The trace levels have the following messages:</p>
+
<list>
<item>1: Verbose error messages</item>
<item>2: Above messages and verbose warning messages</item>
- <item>3: Above messages and progress reports for connection handling</item>
+ <item>3: Above messages and progress reports for connection handling
+ </item>
<item>4: Above messages and progress reports for communication</item>
<item>5: Above messages and progress reports for data conversion</item>
</list>
diff --git a/lib/erl_interface/doc/src/ei_users_guide.xml b/lib/erl_interface/doc/src/ei_users_guide.xml
index 4beb4c6c73..9499a07467 100644
--- a/lib/erl_interface/doc/src/ei_users_guide.xml
+++ b/lib/erl_interface/doc/src/ei_users_guide.xml
@@ -22,7 +22,7 @@
</legalnotice>
- <title>The El Library User's Guide</title>
+ <title>Erl_Interface User's Guide</title>
<prepared>Kent Boortz</prepared>
<responsible>Kent Boortz</responsible>
<docno></docno>
@@ -32,100 +32,158 @@
<rev></rev>
<file>ei_users_guide.xml</file>
</header>
- <p>The Erl_Interface library contains functions. which help you
- integrate programs written in C and Erlang. The functions in
- Erl_Interface support the following:</p>
- <list type="bulleted">
- <item>manipulation of data represented as Erlang data types</item>
- <item>conversion of data between C and Erlang formats</item>
- <item>encoding and decoding of Erlang data types for transmission or storage</item>
- <item>communication between C nodes and Erlang processes</item>
- <item>backup and restore of C node state to and from Mnesia</item>
- </list>
- <p>In the following sections, these topics are described:</p>
- <list type="bulleted">
- <item>compiling your code for use with Erl_Interface</item>
- <item>initializing Erl_Interface</item>
- <item>encoding, decoding, and sending Erlang terms</item>
- <item>building terms and patterns</item>
- <item>pattern matching</item>
- <item>connecting to a distributed Erlang node</item>
- <item>using EPMD</item>
- <item>sending and receiving Erlang messages</item>
- <item>remote procedure calls</item>
- <item>global names</item>
- <item>the registry</item>
- </list>
+
+ <section>
+ <title>Introduction</title>
+ <p>The <c>Erl_Interface</c> library contains functions that help you
+ integrate programs written in C and Erlang. The functions in
+ <c>Erl_Interface</c> support the following:</p>
+ <list type="bulleted">
+ <item>Manipulation of data represented as Erlang data types</item>
+ <item>Conversion of data between C and Erlang formats</item>
+ <item>Encoding and decoding of Erlang data types for transmission or
+ storage</item>
+ <item>Communication between C nodes and Erlang processes</item>
+ <item>Backup and restore of C node state to and from
+ <seealso marker="mnesia"><c>Mnesia</c></seealso></item>
+ </list>
+ <note>
+ <p>By default, the <c>Erl_Interface</c> libraries are only guaranteed
+ to be compatible with other Erlang/OTP components from the same
+ release as the libraries themselves. For information about how to
+ communicate with Erlang/OTP components from earlier releases, see
+ function <seealso marker="ei#ei_set_compat_rel">
+ <c>ei:ei_set_compat_rel</c></seealso> and
+ <seealso marker="erl_eterm#erl_set_compat_rel">
+ <c>erl_eterm:erl_set_compat_rel</c></seealso>.</p>
+ </note>
+
+ <section>
+ <title>Scope</title>
+ <p>In the following sections, these topics are described:</p>
+ <list type="bulleted">
+ <item>Compiling your code for use with <c>Erl_Interface</c></item>
+ <item>Initializing <c>Erl_Interface</c></item>
+ <item>Encoding, decoding, and sending Erlang terms</item>
+ <item>Building terms and patterns</item>
+ <item>Pattern matching</item>
+ <item>Connecting to a distributed Erlang node</item>
+ <item>Using the Erlang Port Mapper Daemon (EPMD)</item>
+ <item>Sending and receiving Erlang messages</item>
+ <item>Remote procedure calls</item>
+ <item>Using global names</item>
+ <item>Using the registry</item>
+ </list>
+ </section>
+
+ <section>
+ <title>Prerequisites</title>
+ <p>It is assumed that the reader is familiar with the Erlang programming
+ language.</p>
+ </section>
+ </section>
<section>
<title>Compiling and Linking Your Code</title>
- <p>In order to use any of the Erl_Interface functions, include the
+ <p>To use any of the <c>Erl_Interface</c> functions, include the
following lines in your code:</p>
+
<code type="none"><![CDATA[
#include "erl_interface.h"
#include "ei.h" ]]></code>
- <p>Determine where the top directory of your OTP installation is. You
- can find this out by starting Erlang and entering the following
+
+ <p>Determine where the top directory of your OTP installation is.
+ To find this, start Erlang and enter the following
command at the Eshell prompt:</p>
+
<code type="none"><![CDATA[
Eshell V4.7.4 (abort with ^G)
1> code:root_dir().
/usr/local/otp ]]></code>
- <p>To compile your code, make sure that your C compiler knows where
- to find <c><![CDATA[erl_interface.h]]></c> by specifying an appropriate <c><![CDATA[-I]]></c>
- argument on the command line, or by adding it to the <c><![CDATA[CFLAGS]]></c>
- definition in your <c><![CDATA[Makefile]]></c>. The correct value for this path is
- <c><![CDATA[$OTPROOT/lib/erl_interface]]></c><em>Vsn</em><c><![CDATA[/include]]></c>, where <c><![CDATA[$OTPROOT]]></c> is the path
- reported by <c><![CDATA[code:root_dir/0]]></c> in the above example, and <em>Vsn</em> is
- the version of the Erl_interface application, for example
- <c><![CDATA[erl_interface-3.2.3]]></c></p>
+
+ <p>To compile your code, ensure that your C compiler knows where
+ to find <c><![CDATA[erl_interface.h]]></c> by specifying an appropriate
+ <c><![CDATA[-I]]></c> argument on the command line, or add it to
+ the <c><![CDATA[CFLAGS]]></c> definition in your
+ <c><![CDATA[Makefile]]></c>. The correct value for this path is
+ <c><![CDATA[$OTPROOT/lib/erl_interface]]></c><em>Vsn</em><c><![CDATA[/include]]></c>,
+ where:</p>
+
+ <list type="bulleted">
+ <item>
+ <p><c><![CDATA[$OTPROOT]]></c> is the path reported by
+ <c><![CDATA[code:root_dir/0]]></c> in the example above.</p>
+ </item>
+ <item>
+ <p><em>Vsn</em> is the version of the <c>Erl_Interface</c> application,
+ for example, <c><![CDATA[erl_interface-3.2.3]]></c>.</p>
+ </item>
+ </list>
+
+ <p>Compiling the code:</p>
+
<code type="none"><![CDATA[
$ cc -c -I/usr/local/otp/lib/erl_interface-3.2.3/include myprog.c ]]></code>
- <p>When linking, you will need to specify the path to
- <c><![CDATA[liberl_interface.a]]></c> and <c><![CDATA[libei.a]]></c> with
- <c><![CDATA[-L$OTPROOT/lib/erl_interface-3.2.3/lib]]></c>, and you will need to specify the
- name of the libraries with <c><![CDATA[-lerl_interface -lei]]></c>. You can do
- this on the command line or by adding the flags to the <c><![CDATA[LDFLAGS]]></c>
- definition in your <c><![CDATA[Makefile]]></c>.</p>
+
+ <p>When linking:</p>
+
+ <list type="bulleted">
+ <item>Specify the path to <c><![CDATA[liberl_interface.a]]></c> and
+ <c><![CDATA[libei.a]]></c> with
+ <c><![CDATA[-L$OTPROOT/lib/erl_interface-3.2.3/lib]]></c>.</item>
+ <item>Specify the name of the libraries with
+ <c><![CDATA[-lerl_interface -lei]]></c>.</item>
+ </list>
+
+ <p>Do this on the command line or add the flags to the
+ <c><![CDATA[LDFLAGS]]></c> definition in your
+ <c><![CDATA[Makefile]]></c>.</p>
+
+ <p>Linking the code:</p>
+
<code type="none"><![CDATA[
$ ld -L/usr/local/otp/lib/erl_interface-3.2.3/
lib myprog.o -lerl_interface -lei -o myprog ]]></code>
- <p>Also, on some systems it may be necessary to link with some
- additional libraries (e.g. <c><![CDATA[libnsl.a]]></c> and <c><![CDATA[libsocket.a]]></c> on
- Solaris, or <c><![CDATA[wsock32.lib]]></c> on Windows) in order to use the
- communication facilities of Erl_Interface.</p>
- <p>If you are using Erl_Interface functions in a threaded
+
+ <p>On some systems it can be necessary to link with some more
+ libraries (for example, <c><![CDATA[libnsl.a]]></c> and
+ <c><![CDATA[libsocket.a]]></c> on Solaris, or
+ <c><![CDATA[wsock32.lib]]></c> on Windows) to use the
+ communication facilities of <c>Erl_Interface</c>.</p>
+
+ <p>If you use the <c>Erl_Interface</c> functions in a threaded
application based on POSIX threads or Solaris threads, then
- Erl_Interface needs access to some of the synchronization
- facilities in your threads package, and you will need to specify
- additional compiler flags in order to indicate which of the packages
- you are using. Define <c><![CDATA[_REENTRANT]]></c> and either <c><![CDATA[STHREADS]]></c> or
+ <c>Erl_Interface</c> needs access to some of the synchronization
+ facilities in your threads package. You must specify extra
+ compiler flags to indicate which of the packages you use. Define
+ <c><![CDATA[_REENTRANT]]></c> and either <c><![CDATA[STHREADS]]></c> or
<c><![CDATA[PTHREADS]]></c>. The default is to use POSIX threads if
<c><![CDATA[_REENTRANT]]></c> is specified.</p>
</section>
<section>
- <title>Initializing the erl_interface Library</title>
- <p>Before calling any of the other Erl_Interface functions, you
- must call <c><![CDATA[erl_init()]]></c> exactly once to initialize the library.
- <c><![CDATA[erl_init()]]></c> takes two arguments, however the arguments are no
- longer used by Erl_Interface, and should therefore be specified
- as <c><![CDATA[erl_init(NULL,0)]]></c>.</p>
+ <title>Initializing the Erl_Interface Library</title>
+ <p>Before calling any of the other <c>Erl_Interface</c> functions, call
+ <c><![CDATA[erl_init()]]></c> exactly once to initialize the library.
+ <c><![CDATA[erl_init()]]></c> takes two arguments. However, the arguments
+ are no longer used by <c>Erl_Interface</c> and are therefore to be
+ specified as <c><![CDATA[erl_init(NULL,0)]]></c>.</p>
</section>
<section>
- <title>Encoding, Decoding and Sending Erlang Terms</title>
+ <title>Encoding, Decoding, and Sending Erlang Terms</title>
<p>Data sent between distributed Erlang nodes is encoded in the
- Erlang external format. Consequently, you have to encode and decode
+ Erlang external format. You must therefore encode and decode
Erlang terms into byte streams if you want to use the distribution
- protocol to communicate between a C program and Erlang. </p>
- <p>The Erl_Interface library supports this activity. It has a
- number of C functions which create and manipulate Erlang data
+ protocol to communicate between a C program and Erlang.</p>
+
+ <p>The <c>Erl_Interface</c> library supports this activity. It has
+ several C functions that create and manipulate Erlang data
structures. The library also contains an encode and a decode function.
- The example below shows how to create and encode an Erlang tuple
+ The following example shows how to create and encode an Erlang tuple
<c><![CDATA[{tobbe,3928}]]></c>:</p>
- <code type="none"><![CDATA[
+ <code type="none"><![CDATA[
ETERM *arr[2], *tuple;
char buf[BUFSIZ];
int i;
@@ -134,58 +192,70 @@ arr[0] = erl_mk_atom("tobbe");
arr[1] = erl_mk_integer(3928);
tuple = erl_mk_tuple(arr, 2);
i = erl_encode(tuple, buf); ]]></code>
+
<p>Alternatively, you can use <c><![CDATA[erl_send()]]></c> and
- <c><![CDATA[erl_receive_msg]]></c>, which handle the encoding and decoding of
- messages transparently.</p>
- <p>Refer to the Reference Manual for a complete description of the
- following modules:</p>
+ <c><![CDATA[erl_receive_msg]]></c>, which handle the encoding and
+ decoding of messages transparently.</p>
+
+ <p>For a complete description, see the following modules:</p>
<list type="bulleted">
- <item>the <c><![CDATA[erl_eterm]]></c> module for creating Erlang terms</item>
- <item>the <c><![CDATA[erl_marshal]]></c> module for encoding and decoding routines.</item>
+ <item><seealso marker="erl_eterm"><c>erl_eterm</c></seealso>
+ for creating Erlang terms</item>
+ <item><seealso marker="erl_marshal"><c>erl_marshal</c></seealso>
+ for encoding and decoding routines</item>
</list>
</section>
<section>
+ <marker id="building terms and patterns"/>
<title>Building Terms and Patterns</title>
- <p>The previous example can be simplified by using
- <c><![CDATA[erl_format()]]></c> to create an Erlang term.</p>
- <code type="none"><![CDATA[
+ <p>The previous example can be simplified by using the
+ <seealso marker="erl_format"><c>erl_format</c></seealso> module
+ to create an Erlang term:</p>
+ <code type="none"><![CDATA[
ETERM *ep;
ep = erl_format("{~a,~i}", "tobbe", 3928); ]]></code>
- <p>Refer to the Reference Manual, the <c><![CDATA[erl_format]]></c> module, for a
- full description of the different format directives. The following
- example is more complex:</p>
- <code type="none"><![CDATA[
+ <p>For a complete description of the different format directives, see
+ the <seealso marker="erl_format"><c>erl_format</c></seealso> module.</p>
+
+ <p>The following example is more complex:</p>
+
+ <code type="none"><![CDATA[
ETERM *ep;
ep = erl_format("[{name,~a},{age,~i},{data,~w}]",
"madonna",
21,
erl_format("[{adr,~s,~i}]", "E-street", 42));
erl_free_compound(ep); ]]></code>
- <p>As in previous examples, it is your responsibility to free the
- memory allocated for Erlang terms. In this example,
- <c><![CDATA[erl_free_compound()]]></c> ensures that the complete term pointed to
- by <c><![CDATA[ep]]></c> is released. This is necessary, because the pointer from
- the second call to <c><![CDATA[erl_format()]]></c> is lost. </p>
- <p>The following
- example shows a slightly different solution:</p>
- <code type="none"><![CDATA[
+ <p>As in the previous examples, it is your responsibility to free the
+ memory allocated for Erlang terms. In this example,
+ <c><![CDATA[erl_free_compound()]]></c> ensures that the complete term
+ pointed to by <c><![CDATA[ep]]></c> is released. This is necessary
+ because the pointer from the second call to <c>erl_format</c> is lost.</p>
+
+ <p>The following example shows a slightly different solution:</p>
+
+ <code type="none"><![CDATA[
ETERM *ep,*ep2;
ep2 = erl_format("[{adr,~s,~i}]","E-street",42);
ep = erl_format("[{name,~a},{age,~i},{data,~w}]",
"madonna", 21, ep2);
erl_free_term(ep);
erl_free_term(ep2); ]]></code>
+
<p>In this case, you free the two terms independently. The order in
- which you free the terms <c><![CDATA[ep]]></c> and <c><![CDATA[ep2]]></c> is not important,
- because the Erl_Interface library uses reference counting to
- determine when it is safe to actually remove objects. </p>
- <p>If you are not sure whether you have freed the terms properly, you
+ which you free the terms <c><![CDATA[ep]]></c> and <c><![CDATA[ep2]]></c>
+ is not important,
+ because the <c>Erl_Interface</c> library uses reference counting to
+ determine when it is safe to remove objects.</p>
+
+ <p>If you are unsure whether you have freed the terms properly, you
can use the following function to see the status of the fixed term
allocator:</p>
+
<code type="none"><![CDATA[
long allocated, freed;
@@ -196,36 +266,49 @@ printf("length of freelist: %ld\n",freed);
/* really free the freelist */
erl_eterm_release();
]]></code>
- <p>Refer to the Reference Manual, the <c><![CDATA[erl_malloc]]></c> module for more
- information.</p>
+
+ <p>For more information, see the
+ <seealso marker="erl_malloc"><c>erl_malloc</c></seealso> module.</p>
</section>
<section>
<title>Pattern Matching</title>
- <p>An Erlang pattern is a term that may contain unbound variables or
- <c><![CDATA["do not care"]]></c> symbols. Such a pattern can be matched against a
+ <p>An Erlang pattern is a term that can contain unbound variables or
+ <c><![CDATA["do not care"]]></c> symbols. Such a pattern can be matched
+ against a
term and, if the match is successful, any unbound variables in the
pattern will be bound as a side effect. The content of a bound
- variable can then be retrieved.</p>
- <code type="none"><![CDATA[
+ variable can then be retrieved:</p>
+ <code type="none"><![CDATA[
ETERM *pattern;
pattern = erl_format("{madonna,Age,_}"); ]]></code>
- <p><c><![CDATA[erl_match()]]></c> is used to perform pattern matching. It takes a
+
+ <p>The <seealso marker="erl_format#erl_match">
+ <c>erl_format:erl_match</c></seealso> function
+ performs pattern matching. It takes a
pattern and a term and tries to match them. As a side effect any unbound
- variables in the pattern will be bound. In the following example, we
- create a pattern with a variable <em>Age</em> which appears at two
+ variables in the pattern will be bound. In the following example, a
+ pattern is created with a variable <c>Age</c>, which is included at two
positions in the tuple. The pattern match is performed as follows:</p>
- <list type="ordered">
- <item><c><![CDATA[erl_match()]]></c> will bind the contents of
- <em>Age</em> to <em>21</em> the first time it reaches the variable</item>
- <item>the second occurrence of <em>Age</em> will cause a test for
- equality between the terms since <em>Age</em> is already bound to
- <em>21</em>. Since <em>Age</em> is bound to 21, the equality test will
- succeed and the match continues until the end of the pattern.</item>
- <item>if the end of the pattern is reached, the match succeeds and you
- can retrieve the contents of the variable</item>
+
+ <list type="bulleted">
+ <item>
+ <p><c>erl_match</c> binds the contents of <c>Age</c> to <c>21</c>
+ the first time it reaches the variable.</p>
+ </item>
+ <item>
+ <p>The second occurrence of <c>Age</c> causes a test for
+ equality between the terms, as <c>Age</c> is already bound to
+ <c>21</c>. As <c>Age</c> is bound to <c>21</c>, the equality test
+ succeeds and the match continues until the end of the pattern.</p>
+ </item>
+ <item>
+ <p>If the end of the pattern is reached, the match succeeds and you
+ can retrieve the contents of the variable.</p>
+ </item>
</list>
+
<code type="none"><![CDATA[
ETERM *pattern,*term;
pattern = erl_format("{madonna,Age,Age}");
@@ -239,99 +322,136 @@ if (erl_match(pattern, term)) {
}
erl_free_term(pattern);
erl_free_term(term); ]]></code>
- <p>Refer to the Reference Manual, the <c><![CDATA[erl_match()]]></c> function for
- more information.</p>
+
+ <p>For more information, see the
+ <seealso marker="erl_format#erl_match">
+ <c>erl_format:erl_match</c></seealso> function.</p>
</section>
<section>
<title>Connecting to a Distributed Erlang Node</title>
- <p>In order to connect to a distributed Erlang node you need to first
- initialize the connection routine with <c><![CDATA[erl_connect_init()]]></c>,
- which stores information such as the host name, node name, and IP
+ <p>To connect to a distributed Erlang node, you must first
+ initialize the connection routine with
+ <seealso marker="erl_connect#erl_connect_init">
+ <c>erl_connect:erl_connect_init</c></seealso>,
+ which stores information, such as the hostname, node name, and IP
address for later use:</p>
+
<code type="none"><![CDATA[
int identification_number = 99;
int creation=1;
char *cookie="a secret cookie string"; /* An example */
erl_connect_init(identification_number, cookie, creation); ]]></code>
- <p>Refer to the Reference Manual, the <c><![CDATA[erl_connect]]></c> module for more information.</p>
+
+ <p>For more information, see the
+ <seealso marker="erl_connect"><c>erl_connect</c></seealso> module.</p>
+
<p>After initialization, you set up the connection to the Erlang node.
- Use <c><![CDATA[erl_connect()]]></c> to specify the Erlang node you want to
- connect to. The following example sets up the connection and should
- result in a valid socket file descriptor:</p>
+ To specify the Erlang node you want to connect to, use
+ <c><![CDATA[erl_connect()]]></c>. The following example sets up the
+ connection and is to result in a valid socket file descriptor:</p>
+
<code type="none"><![CDATA[
int sockfd;
char *nodename="[email protected]"; /* An example */
if ((sockfd = erl_connect(nodename)) < 0)
erl_err_quit("ERROR: erl_connect failed"); ]]></code>
- <p><c><![CDATA[erl_err_quit()]]></c> prints the specified string and terminates
- the program. Refer to the Reference Manual, the <c><![CDATA[erl_error()]]></c>
- function for more information.</p>
+
+ <p><c><![CDATA[erl_err_quit()]]></c> prints the specified string and
+ terminates the program. For more information, see the
+ <seealso marker="erl_error"><c>erl_error</c></seealso> module.</p>
</section>
<section>
<title>Using EPMD</title>
- <p><c><![CDATA[Epmd]]></c> is the Erlang Port Mapper Daemon. Distributed Erlang nodes
- register with <c><![CDATA[epmd]]></c> on the localhost to indicate to other nodes that
- they exist and can accept connections. <c><![CDATA[Epmd]]></c> maintains a register of
+ <p><seealso marker="erts:epmd"><c>erts:epmd</c></seealso>
+ is the Erlang Port Mapper Daemon. Distributed
+ Erlang nodes register with <c><![CDATA[epmd]]></c> on the local host to
+ indicate to other nodes that they exist and can accept connections.
+ <c><![CDATA[epmd]]></c> maintains a register of
node and port number information, and when a node wishes to connect to
- another node, it first contacts <c><![CDATA[epmd]]></c> in order to find out the correct
- port number to connect to.</p>
- <p>When you use <c><![CDATA[erl_connect()]]></c> to connect to an Erlang node, a
- connection is first made to <c><![CDATA[epmd]]></c> and, if the node is known, a
+ another node, it first contacts <c><![CDATA[epmd]]></c> to find the
+ correct port number to connect to.</p>
+
+ <p>When you use
+ <seealso marker="erl_connect"><c>erl_connect</c></seealso>
+ to connect to an Erlang node, a connection is first made to
+ <c><![CDATA[epmd]]></c> and, if the node is known, a
connection is then made to the Erlang node.</p>
- <p>C nodes can also register themselves with <c><![CDATA[epmd]]></c> if they want other
+
+ <p>C nodes can also register themselves with <c><![CDATA[epmd]]></c>
+ if they want other
nodes in the system to be able to find and connect to them.</p>
- <p>Before registering with <c><![CDATA[epmd]]></c>, you need to first create a listen socket
- and bind it to a port. Then:</p>
+
+ <p>Before registering with <c><![CDATA[epmd]]></c>, you must first
+ create a listen socket and bind it to a port. Then:</p>
+
<code type="none"><![CDATA[
int pub;
pub = erl_publish(port); ]]></code>
- <p><c><![CDATA[pub]]></c> is a file descriptor now connected to <c><![CDATA[epmd]]></c>. <c><![CDATA[Epmd]]></c>
- monitors the other end of the connection, and if it detects that the
- connection has been closed, the node will be unregistered. So, if you
- explicitly close the descriptor or if your node fails, it will be
+
+ <p><c><![CDATA[pub]]></c> is a file descriptor now connected to
+ <c><![CDATA[epmd]]></c>. <c><![CDATA[epmd]]></c>
+ monitors the other end of the connection. If it detects that the
+ connection has been closed, the node becomes unregistered. So, if you
+ explicitly close the descriptor or if your node fails, it becomes
unregistered from <c><![CDATA[epmd]]></c>.</p>
- <p>Be aware that on some systems (such as VxWorks), a failed node will
- not be detected by this mechanism since the operating system does not
+
+ <p>Notice that on some systems (such as VxWorks), a failed node is
+ not detected by this mechanism, as the operating system does not
automatically close descriptors that were left open when the node
- failed. If a node has failed in this way, <c><![CDATA[epmd]]></c> will prevent you from
- registering a new node with the old name, since it thinks that the old
+ failed. If a node has failed in this way, <c><![CDATA[epmd]]></c>
+ prevents you from
+ registering a new node with the old name, as it thinks that the old
name is still in use. In this case, you must unregister the name
explicitly:</p>
+
<code type="none"><![CDATA[
erl_unpublish(node); ]]></code>
- <p>This will cause <c><![CDATA[epmd]]></c> to close the connection from the far end. Note
+
+ <p>This causes <c><![CDATA[epmd]]></c> to close the connection from the
+ far end. Notice
that if the name was in fact still in use by a node, the results of
this operation are unpredictable. Also, doing this does not cause the
- local end of the connection to close, so resources may be consumed.</p>
+ local end of the connection to close, so resources can be consumed.</p>
</section>
<section>
<title>Sending and Receiving Erlang Messages</title>
<p>Use one of the following two functions to send messages:</p>
+
<list type="bulleted">
- <item><c><![CDATA[erl_send()]]></c></item>
- <item><c><![CDATA[erl_reg_send()]]></c></item>
+ <item><seealso marker="erl_connect#erl_send">
+ <c>erl_connect:erl_send</c></seealso></item>
+ <item><seealso marker="erl_connect#erl_reg_send">
+ <c>erl_connect:erl_reg_send</c></seealso></item>
</list>
- <p>As in Erlang, it is possible to send messages to a
- <em>Pid</em> or to a registered name. It is easier to send a
- message to a registered name because it avoids the problem of finding
- a suitable <em>Pid</em>.</p>
+
+ <p>As in Erlang, messages can be sent to a
+ pid or to a registered name. It is easier to send a
+ message to a registered name, as it avoids the problem of finding
+ a suitable pid.</p>
+
<p>Use one of the following two functions to receive messages:</p>
+
<list type="bulleted">
- <item><c><![CDATA[erl_receive()]]></c></item>
- <item><c><![CDATA[erl_receive_msg()]]></c></item>
+ <item><seealso marker="erl_connect#erl_receive">
+ <c>erl_connect:erl_receive</c></seealso></item>
+ <item><seealso marker="erl_connect#erl_receive_msg">
+ <c>erl_connect:erl_receive_msg</c></seealso></item>
</list>
- <p><c><![CDATA[erl_receive()]]></c> receives the message into a buffer, while
- <c><![CDATA[erl_receive_msg()]]></c> decodes the message into an Erlang term. </p>
+
+ <p><c><![CDATA[erl_receive()]]></c> receives the message into a buffer,
+ while <c><![CDATA[erl_receive_msg()]]></c> decodes the message into an
+ Erlang term.</p>
<section>
<title>Example of Sending Messages</title>
<p>In the following example, <c><![CDATA[{Pid, hello_world}]]></c> is
- sent to a registered process <c><![CDATA[my_server]]></c>. The message is encoded
- by <c><![CDATA[erl_send()]]></c>:</p>
+ sent to a registered process <c><![CDATA[my_server]]></c>. The message
+ is encoded by <c><![CDATA[erl_send()]]></c>:</p>
+
<code type="none"><![CDATA[
extern const char *erl_thisnodename(void);
extern short erl_thiscreation(void);
@@ -345,16 +465,19 @@ emsg = erl_mk_tuple(arr, 2);
erl_reg_send(sockfd, "my_server", emsg);
erl_free_term(emsg); ]]></code>
+
<p>The first element of the tuple that is sent is your own
- <em>Pid</em>. This enables <c><![CDATA[my_server]]></c> to reply. Refer to the
- Reference Manual, the <c><![CDATA[erl_connect]]></c> module for more information
- about send primitives.</p>
+ pid. This enables <c><![CDATA[my_server]]></c> to reply.
+ For more information about the primitives, see the
+ <seealso marker="erl_connect"><c>erl_connect</c></seealso> module.</p>
</section>
<section>
<title>Example of Receiving Messages</title>
- <p>In this example <c><![CDATA[{Pid, Something}]]></c> is received. The
- received Pid is then used to return <c><![CDATA[{goodbye,Pid}]]></c></p>
+ <p>In this example, <c><![CDATA[{Pid, Something}]]></c> is received. The
+ received pid is then used to return
+ <c><![CDATA[{goodbye,Pid}]]></c>.</p>
+
<code type="none"><![CDATA[
ETERM *arr[2], *answer;
int sockfd,rc;
@@ -370,22 +493,25 @@ if ((rc = erl_receive_msg(sockfd , buf, BUFSIZE, &emsg)) == ERL_MSG) {
erl_free_term(emsg.msg);
erl_free_term(emsg.to);
} ]]></code>
- <p>In order to provide robustness, a distributed Erlang node
- occasionally polls all its connected neighbours in an attempt to
- detect failed nodes or communication links. A node which receives such
- a message is expected to respond immediately with an <c><![CDATA[ERL_TICK]]></c> message.
- This is done automatically by <c><![CDATA[erl_receive()]]></c>, however when this
- has occurred <c><![CDATA[erl_receive]]></c> returns <c><![CDATA[ERL_TICK]]></c> to the caller
- without storing a message into the <c><![CDATA[ErlMessage]]></c> structure.</p>
+
+ <p>To provide robustness, a distributed Erlang node
+ occasionally polls all its connected neighbors in an attempt to
+ detect failed nodes or communication links. A node that receives such
+ a message is expected to respond immediately with an
+ <c><![CDATA[ERL_TICK]]></c> message. This is done automatically by
+ <c><![CDATA[erl_receive()]]></c>. However, when this has occurred,
+ <c><![CDATA[erl_receive]]></c> returns <c><![CDATA[ERL_TICK]]></c> to
+ the caller without storing a message into the
+ <c><![CDATA[ErlMessage]]></c> structure.</p>
+
<p>When a message has been received, it is the caller's responsibility
- to free the received message <c><![CDATA[emsg.msg]]></c> as well as <c><![CDATA[emsg.to]]></c>
- or <c><![CDATA[emsg.from]]></c>, depending on the type of message received.</p>
- <p>Refer to the Reference Manual for additional information about the
- following modules:</p>
- <list type="bulleted">
- <item><c><![CDATA[erl_connect]]></c></item>
- <item><c><![CDATA[erl_eterm]]></c>.</item>
- </list>
+ to free the received message <c><![CDATA[emsg.msg]]></c> and
+ <c><![CDATA[emsg.to]]></c> or <c><![CDATA[emsg.from]]></c>,
+ depending on the type of message received.</p>
+
+ <p>For more information, see the
+ <seealso marker="erl_connect"><c>erl_connect</c></seealso> and
+ <seealso marker="erl_eterm"><c>erl_eterm</c></seealso> modules.</p>
</section>
</section>
@@ -394,10 +520,12 @@ if ((rc = erl_receive_msg(sockfd , buf, BUFSIZE, &emsg)) == ERL_MSG) {
<p>An Erlang node acting as a client to another Erlang node
typically sends a request and waits for a reply. Such a request is
included in a function call at a remote node and is called a remote
- procedure call. The following example shows how the
- Erl_Interface library supports remote procedure calls:</p>
- <code type="none"><![CDATA[
+ procedure call.</p>
+ <p>The following example shows how the
+ <c>Erl_Interface</c> library supports remote procedure calls:</p>
+
+ <code type="none"><![CDATA[
char modname[]=THE_MODNAME;
ETERM *reply,*ep;
ep = erl_format("[~a,[]]", modname);
@@ -409,26 +537,34 @@ if (!erl_match(ep, reply))
erl_err_msg("<ERROR> compiler errors !\n");
erl_free_term(ep);
erl_free_term(reply); ]]></code>
- <p><c><![CDATA[c:c/1]]></c> is called to compile the specified module on the
- remote node. <c><![CDATA[erl_match()]]></c> checks that the compilation was
+
+ <p><c><![CDATA[c:c/1]]></c> is called to compile the specified module on
+ the remote node. <c><![CDATA[erl_match()]]></c> checks that the
+ compilation was
successful by testing for the expected <c><![CDATA[ok]]></c>.</p>
- <p>Refer to the Reference Manual, the <c><![CDATA[erl_connect]]></c> module for
- more information about <c><![CDATA[erl_rpc()]]></c>, and its companions
- <c><![CDATA[erl_rpc_to()]]></c> and <c><![CDATA[erl_rpc_from()]]></c>.</p>
+
+ <p>For more information about <c><![CDATA[erl_rpc()]]></c> and its
+ companions <c><![CDATA[erl_rpc_to()]]></c> and
+ <c><![CDATA[erl_rpc_from()]]></c>, see the
+ <seealso marker="erl_connect"><c>erl_connect</c></seealso> module.</p>
</section>
<section>
<title>Using Global Names</title>
- <p>A C node has access to names registered through the Erlang Global
+ <p>A C node has access to names registered through the
+ <seealso marker="kernel:global"><c>kernel:global</c></seealso>
module. Names can be looked up, allowing the C node to send messages
to named Erlang services. C nodes can also register global names,
allowing them to provide named services to Erlang processes or other C
- nodes. </p>
- <p>Erl_Interface does not provide a native implementation of the global
- service. Instead it uses the global services provided by a "nearby"
- Erlang node. In order to use the services described in this section,
+ nodes.</p>
+
+ <p><c>Erl_Interface</c> does not provide a native implementation of the
+ global service. Instead it uses the global services provided by a "nearby"
+ Erlang node. To use the services described in this section,
it is necessary to first open a connection to an Erlang node.</p>
+
<p>To see what names there are:</p>
+
<code type="none"><![CDATA[
char **names;
int count;
@@ -441,71 +577,102 @@ if (names)
printf("%s\n",names[i]);
free(names); ]]></code>
- <p><c><![CDATA[erl_global_names()]]></c> allocates and returns a buffer containing
- all the names known to global. <c><![CDATA[count]]></c> will be initialized to
- indicate how many names are in the array. The array of strings in
- names is terminated by a NULL pointer, so it is not necessary to use
+
+ <p><seealso marker="erl_global#erl_global_names">
+ <c>erl_global:erl_global_names</c></seealso>
+ allocates and returns a buffer containing
+ all the names known to the <c>global</c> module in <c>Kernel</c>.
+ <c><![CDATA[count]]></c> is initialized to
+ indicate the number of names in the array. The array of strings in names
+ is terminated by a <c>NULL</c> pointer, so it is not necessary to use
<c><![CDATA[count]]></c> to determine when the last name is reached.</p>
+
<p>It is the caller's responsibility to free the array.
- <c><![CDATA[erl_global_names()]]></c> allocates the array and all of the strings
- using a single call to <c><![CDATA[malloc()]]></c>, so <c><![CDATA[free(names)]]></c> is all
- that is necessary.</p>
+ <c>erl_global_names</c> allocates the array and all the strings
+ using a single call to <c><![CDATA[malloc()]]></c>, so
+ <c><![CDATA[free(names)]]></c> is all that is necessary.</p>
+
<p>To look up one of the names:</p>
+
<code type="none"><![CDATA[
ETERM *pid;
char node[256];
pid = erl_global_whereis(fd,"schedule",node); ]]></code>
- <p>If <c><![CDATA["schedule"]]></c> is known to global, an Erlang pid is returned
- that can be used to send messages to the schedule service.
- Additionally, <c><![CDATA[node]]></c> will be initialized to contain the name of
+
+ <p>If <c><![CDATA["schedule"]]></c> is known to the
+ <c>global</c> module in <c>Kernel</c>, an Erlang pid is
+ returned that can be used to send messages to the schedule service.
+ Also, <c><![CDATA[node]]></c> is initialized to contain the name of
the node where the service is registered, so that you can make a
- connection to it by simply passing the variable to <c><![CDATA[erl_connect()]]></c>.</p>
+ connection to it by simply passing the variable to
+ <seealso marker="erl_connect"><c>erl_connect</c></seealso>.</p>
+
<p>Before registering a name, you should already have registered your
- port number with <c><![CDATA[epmd]]></c>. This is not strictly necessary, but if you
+ port number with <c><![CDATA[epmd]]></c>. This is not strictly necessary,
+ but if you
neglect to do so, then other nodes wishing to communicate with your
- service will be unable to find or connect to your process.</p>
+ service cannot find or connect to your process.</p>
+
<p>Create a pid that Erlang processes can use to communicate with your
service:</p>
+
<code type="none"><![CDATA[
ETERM *pid;
pid = erl_mk_pid(thisnode,14,0,0);
erl_global_register(fd,servicename,pid); ]]></code>
- <p>After registering the name, you should use <c><![CDATA[erl_accept()]]></c> to wait for
- incoming connections.</p>
- <p>Do not forget to free <c><![CDATA[pid]]></c> later with <c><![CDATA[erl_free_term()]]></c>!</p>
+
+ <p>After registering the name, use
+ <seealso marker="erl_connect#erl_accept">
+ <c>erl_connect:erl_accept</c></seealso>
+ to wait for incoming connections.</p>
+
+ <note>
+ <p>Remember to free <c><![CDATA[pid]]></c> later with
+ <seealso marker="erl_malloc#erl_free_term">
+ <c>erl_malloc:erl_free_term</c></seealso>.</p>
+ </note>
+
<p>To unregister a name:</p>
+
<code type="none"><![CDATA[
erl_global_unregister(fd,servicename); ]]></code>
</section>
<section>
- <title>The Registry</title>
+ <title>Using the Registry</title>
<p>This section describes the use of the registry, a simple mechanism
for storing key-value pairs in a C-node, as well as backing them up or
- restoring them from a Mnesia table on an Erlang node. More detailed
- information about the individual API functions can be found in the
- Reference Manual.</p>
- <p>Keys are strings, i.e. 0-terminated arrays of characters, and values
- are arbitrary objects. Although integers and floating point numbers
+ restoring them from an <c>Mnesia</c> table on an Erlang node. For more
+ detailed information about the individual API functions, see the
+ <seealso marker="registry"><c>registry</c></seealso> module.</p>
+
+ <p>Keys are strings, that is, zero-terminated arrays of characters, and
+ values are arbitrary objects. Although integers and floating point numbers
are treated specially by the registry, you can store strings or binary
objects of any type as pointers.</p>
- <p>To start, you need to open a registry:</p>
+
+ <p>To start, open a registry:</p>
+
<code type="none"><![CDATA[
ei_reg *reg;
reg = ei_reg_open(45); ]]></code>
- <p>The number 45 in the example indicates the approximate number of
+
+ <p>The number <c>45</c> in the example indicates the approximate number of
objects that you expect to store in the registry. Internally the
registry uses hash tables with collision chaining, so there is no
absolute upper limit on the number of objects that the registry can
- contain, but if performance or memory usage are important, then you
- should choose a number accordingly. The registry can be resized later.</p>
+ contain, but if performance or memory usage is important, then you
+ are to choose a number accordingly. The registry can be resized later.</p>
+
<p>You can open as many registries as you like (if memory permits).</p>
- <p>Objects are stored and retrieved through set and get functions. In
- the following examples you see how to store integers, floats, strings
+
+ <p>Objects are stored and retrieved through set and get functions.
+ The following example shows how to store integers, floats, strings,
and arbitrary binary objects:</p>
+
<code type="none"><![CDATA[
struct bonk *b = malloc(sizeof(*b));
char *name = malloc(7);
@@ -519,13 +686,16 @@ ei_reg_setsval(reg,"name",name);
b->l = 42;
b->m = 12;
ei_reg_setpval(reg,"jox",b,sizeof(*b)); ]]></code>
- <p>If you attempt to store an object in the registry and there is an
- existing object with the same key, the new value will replace the old
+
+ <p>If you try to store an object in the registry and there is an
+ existing object with the same key, the new value replaces the old
one. This is done regardless of whether the new object and the old one
have the same type, so you can, for example, replace a string with an
- integer. If the existing value is a string or binary, it will be freed
+ integer. If the existing value is a string or binary, it is freed
before the new value is assigned.</p>
+
<p>Stored values are retrieved from the registry as follows:</p>
+
<code type="none"><![CDATA[
long i;
double f;
@@ -537,76 +707,100 @@ i = ei_reg_getival(reg,"age");
f = ei_reg_getfval(reg,"height");
s = ei_reg_getsval(reg,"name");
b = ei_reg_getpval(reg,"jox",&size); ]]></code>
- <p>In all of the above examples, the object must exist and it must be of
+
+ <p>In all the above examples, the object must exist and it must be of
the right type for the specified operation. If you do not know the
- type of a given object, you can ask:</p>
+ type of an object, you can ask:</p>
+
<code type="none"><![CDATA[
struct ei_reg_stat buf;
ei_reg_stat(reg,"name",&buf); ]]></code>
- <p>Buf will be initialized to contain object attributes.</p>
+
+ <p>Buf is initialized to contain object attributes.</p>
+
<p>Objects can be removed from the registry:</p>
+
<code type="none"><![CDATA[
ei_reg_delete(reg,"name"); ]]></code>
+
<p>When you are finished with a registry, close it to remove all the
objects and free the memory back to the system:</p>
+
<code type="none"><![CDATA[
ei_reg_close(reg); ]]></code>
<section>
<title>Backing Up the Registry to Mnesia</title>
- <p>The contents of a registry can be backed up to Mnesia on a "nearby"
- Erlang node. You need to provide an open connection to the Erlang node
- (see <c><![CDATA[erl_connect()]]></c>). Also, Mnesia 3.0 or later must be running
+ <p>The contents of a registry can be backed up to
+ <seealso marker="mnesia"><c>Mnesia</c></seealso> on a "nearby" Erlang
+ node. You must provide an open connection to the Erlang node
+ (see <seealso marker="erl_connect"><c>erl_connect</c></seealso>).
+ Also, <c>Mnesia</c> 3.0 or later must be running
on the Erlang node before the backup is initiated:</p>
+
<code type="none"><![CDATA[
ei_reg_dump(fd, reg, "mtab", dumpflags); ]]></code>
- <p>The example above will backup the contents of the registry to the
- specified Mnesia table <c><![CDATA["mtab"]]></c>. Once a registry has been backed
- up to Mnesia in this manner, additional backups will only affect
- objects that have been modified since the most recent backup, i.e.
- objects that have been created, changed or deleted. The backup
- operation is done as a single atomic transaction, so that the entire
- backup will be performed or none of it will.</p>
- <p>In the same manner, a registry can be restored from a Mnesia table:</p>
+
+ <p>This example back up the contents of the registry to the
+ specified <c>Mnesia</c> table <c><![CDATA["mtab"]]></c>.
+ Once a registry has been backed
+ up to <c>Mnesia</c> like this, more backups only affect
+ objects that have been modified since the most recent backup, that is,
+ objects that have been created, changed, or deleted. The backup
+ operation is done as a single atomic transaction, so that either the
+ entire backup is performed or none of it.</p>
+
+ <p>Likewise, a registry can be restored from a <c>Mnesia</c> table:</p>
+
<code type="none"><![CDATA[
ei_reg_restore(fd, reg, "mtab"); ]]></code>
- <p>This will read the entire contents of <c><![CDATA["mtab"]]></c> into the specified
- registry. After the restore, all of the objects in the registry will
- be marked as unmodified, so a subsequent backup will only affect
+
+ <p>This reads the entire contents of <c><![CDATA["mtab"]]></c> into the
+ specified registry. After the restore, all the objects in the registry
+ are marked as unmodified, so a later backup only affects
objects that you have modified since the restore.</p>
- <p>Note that if you restore to a non-empty registry, objects in the
- table will overwrite objects in the registry with the same keys. Also,
+
+ <p>Notice that if you restore to a non-empty registry, objects in the
+ table overwrite objects in the registry with the same keys. Also,
the <em>entire</em> contents of the registry is marked as unmodified
after the restore, including any modified objects that were not
- overwritten by the restore operation. This may not be your intention.</p>
+ overwritten by the restore operation. This may not be your
+ intention.</p>
</section>
<section>
<title>Storing Strings and Binaries</title>
<p>When string or binary objects are stored in the registry it is
- important that a number of simple guidelines are followed. </p>
+ important that some simple guidelines are followed.</p>
+
<p>Most importantly, the object must have been created with a single call
- to <c><![CDATA[malloc()]]></c> (or similar), so that it can later be removed by a
- single call to <c><![CDATA[free()]]></c>. Objects will be freed by the registry
+ to <c><![CDATA[malloc()]]></c> (or similar), so that it can later be
+ removed by a single call to <c><![CDATA[free()]]></c>.
+ Objects are freed by the registry
when it is closed, or when you assign a new value to an object that
previously contained a string or binary.</p>
- <p>You should also be aware that if you store binary objects that are
- context-dependent (e.g. containing pointers or open file descriptors),
- they will lose their meaning if they are backed up to a Mnesia table
- and subsequently restored in a different context.</p>
+
+ <p>Notice that if you store binary objects that are context-dependent
+ (for example, containing pointers or open file descriptors),
+ they lose their meaning if they are backed up to a <c>Mnesia</c> table
+ and later restored in a different context.</p>
+
<p>When you retrieve a stored string or binary value from the registry,
the registry maintains a pointer to the object and you are passed a
copy of that pointer. You should never free an object retrieved in
this manner because when the registry later attempts to free it, a
- runtime error will occur that will likely cause the C-node to crash.</p>
+ runtime error occurs that likely causes the C-node to crash.</p>
+
<p>You are free to modify the contents of an object retrieved this way.
- However when you do so, the registry will not be aware of the changes
- you make, possibly causing it to be missed the next time you make a
- Mnesia backup of the registry contents. This can be avoided if you
- mark the object as dirty after any such changes with
- <c><![CDATA[ei_reg_markdirty()]]></c>, or pass appropriate flags to
- <c><![CDATA[ei_reg_dump()]]></c>.</p>
+ However, when you do so, the registry is not aware of your changes,
+ possibly causing it to be missed the next time you make an
+ <c>Mnesia</c> backup of the registry contents. This can be avoided if
+ you mark the object as dirty after any such changes with
+ <seealso marker="registry#ei_reg_markdirty">
+ <c>registry:ei_reg_markdirty</c></seealso>, or pass appropriate flags to
+ <seealso marker="registry#ei_reg_dump">
+ <c>registry:ei_reg_dump</c></seealso>.</p>
</section>
</section>
</chapter>
diff --git a/lib/erl_interface/doc/src/erl_call.xml b/lib/erl_interface/doc/src/erl_call.xml
index f8fe409560..ebd9172f98 100644
--- a/lib/erl_interface/doc/src/erl_call.xml
+++ b/lib/erl_interface/doc/src/erl_call.xml
@@ -28,135 +28,146 @@
<docno></docno>
<approved>Bjarne D&auml;cker</approved>
<checked>Torbj&ouml;rn T&ouml;rnkvist</checked>
- <date>97-05-16</date>
+ <date>1997-05-16</date>
<rev>B</rev>
<file>erl_call.xml</file>
</header>
<com>erl_call</com>
<comsummary>Call/start a distributed Erlang node.</comsummary>
<description>
- <p><c><![CDATA[erl_call]]></c> makes it possible to start and/or communicate with
- a distributed Erlang node. It is built upon the <c><![CDATA[erl_interface]]></c>
- library as an example application. Its purpose is to use an Unix shell script to interact with a distributed Erlang node. It performs all
- communication with the Erlang <em>rex server</em>, using the standard Erlang RPC facility. It does not require any special
- software to be run at the Erlang target node.</p>
+ <p><c><![CDATA[erl_call]]></c> makes it possible to start and/or
+ communicate with a distributed Erlang node. It is built upon the
+ <c><![CDATA[Erl_Interface]]></c> library as an example application.
+ Its purpose is to use a Unix shell script to interact with a distributed
+ Erlang node. It performs all communication with the Erlang
+ <em>rex server</em>, using the standard Erlang RPC facility. It does not
+ require any special software to be run at the Erlang target node.</p>
+
<p>The main use is to either start a distributed Erlang node
or to make an ordinary function call. However, it is also
- possible to pipe an Erlang module to <c><![CDATA[erl_call]]></c> and have it
- compiled, or to pipe a sequence of Erlang expressions to be evaluated
+ possible to pipe an Erlang module to <c><![CDATA[erl_call]]></c> and have
+ it compiled, or to pipe a sequence of Erlang expressions to be evaluated
(similar to the Erlang shell).</p>
- <p>Options, which cause <c><![CDATA[stdin]]></c> to be read, can be used with
- advantage
- as scripts from within (Unix) shell scripts. Another
- nice use of <c><![CDATA[erl_call]]></c> could be from (http) CGI-bin scripts.</p>
+
+ <p>Options, which cause <c><![CDATA[stdin]]></c> to be read, can be used
+ with advantage,
+ as scripts from within (Unix) shell scripts. Another nice use
+ of <c><![CDATA[erl_call]]></c> could be from (HTTP) CGI-bin scripts.</p>
</description>
+
<funcs>
<func>
<name>erl_call &lt;options></name>
<fsummary>Start/call Erlang.</fsummary>
<desc>
- <p>Each option flag is described below with its name, type and
+ <p>Starts/calls Erlang.</p>
+ <p>Each option flag is described below with its name, type, and
meaning.</p>
<taglist>
- <tag>-a [Mod [Fun [Args]]]]</tag>
+ <tag><c>-a [Mod [Fun [Args]]]]</c></tag>
<item>
- <p>(<em>optional</em>): Applies the specified function
- and returns the result. <c><![CDATA[Mod]]></c> must be specified, however
- <c>start</c> and <c>[]</c> are assumed for unspecified <c><![CDATA[Fun]]></c> and <c><![CDATA[Args]]></c>, respectively. <c><![CDATA[Args]]></c> should
- be in the same format as for <c><![CDATA[erlang:apply/3]]></c>. Note
- that this flag takes exactly one argument, so quoting
- may be necessary in order to group <c><![CDATA[Mod]]></c>, <c><![CDATA[Fun]]></c>
- and <c><![CDATA[Args]]></c>, in a manner dependent on the behavior
- of your command shell.</p>
- <p></p>
+ <p>(<em>Optional.</em>) Applies the specified function
+ and returns the result. <c><![CDATA[Mod]]></c> must be specified.
+ However, <c>start</c> and <c>[]</c> are assumed for unspecified
+ <c><![CDATA[Fun]]></c> and <c><![CDATA[Args]]></c>, respectively.
+ <c><![CDATA[Args]]></c> is to be in the same format as for
+ <seealso marker="erts:erlang#apply/3">
+ <c>erlang:apply/3</c></seealso> in <c>ERTS</c>.</p>
+ <p>Notice that this flag takes exactly one argument, so quoting
+ can be necessary to group <c><![CDATA[Mod]]></c>,
+ <c><![CDATA[Fun]]></c>, and <c><![CDATA[Args]]></c> in a manner
+ dependent on the behavior of your command shell.</p>
</item>
- <tag>-c Cookie</tag>
+ <tag><c>-c Cookie</c></tag>
<item>
- <p>(<em>optional</em>): Use this option to specify a certain cookie. If no cookie is specified, the <c><![CDATA[~/.erlang.cookie]]></c> file is read and its content are used as cookie. The Erlang node we want to communicate with must have the same cookie.</p>
+ <p>(<em>Optional.</em>) Use this option to specify a certain cookie.
+ If no cookie is specified, the <c><![CDATA[~/.erlang.cookie]]></c>
+ file is read and its content is used as cookie. The Erlang node
+ we want to communicate with must have the same cookie.</p>
</item>
- <tag>-d</tag>
+ <tag><c>-d</c></tag>
<item>
- <p>(<em>optional</em>): Debug mode. This causes all IO to be output
- to the file <c><![CDATA[~/.erl_call.out.Nodename]]></c>, where <c><![CDATA[Nodename]]></c>
+ <p>(<em>Optional.</em>) Debug mode. This causes all I/O to be output
+ to the <c><![CDATA[~/.erl_call.out.Nodename]]></c> file, where
+ <c><![CDATA[Nodename]]></c>
is the node name of the Erlang node in question.</p>
- <p></p>
</item>
- <tag>-e</tag>
+ <tag><c>-e</c></tag>
<item>
- <p>(<em>optional</em>): Reads a sequence of Erlang expressions, separated
- by '<em>,</em>' and ended with a '<em>.</em>', from <c><![CDATA[stdin]]></c> until
- EOF (Control-D). Evaluates the expressions and returns the result from
- the last expression. Returns <c><![CDATA[{ok,Result}]]></c> if successful.</p>
- <p></p>
+ <p>(<em>Optional.</em>) Reads a sequence of Erlang expressions,
+ separated by comma (,) and ended with a full stop (.), from
+ <c><![CDATA[stdin]]></c> until EOF (Control-D). Evaluates the
+ expressions and returns the result from the last expression.
+ Returns <c><![CDATA[{ok,Result}]]></c> on success.</p>
</item>
- <tag>-h HiddenName</tag>
+ <tag><c>-h HiddenName</c></tag>
<item>
- <p>(<em>optional</em>): Specifies the name of the hidden node
+ <p>(<em>Optional.</em>) Specifies the name of the hidden node
that <c><![CDATA[erl_call]]></c> represents.</p>
- <p></p>
</item>
- <tag>-m</tag>
+ <tag><c>-m</c></tag>
<item>
- <p>(<em>optional</em>): Reads an Erlang module from <c><![CDATA[stdin]]></c> and
- compiles it.</p>
- <p></p>
+ <p>(<em>Optional.</em>) Reads an Erlang module from
+ <c><![CDATA[stdin]]></c> and compiles it.</p>
</item>
- <tag>-n Node</tag>
+ <tag><c>-n Node</c></tag>
<item>
- <p>(one of <c><![CDATA[-n, -name, -sname]]></c> is required):
- Has the same meaning as <c><![CDATA[-name]]></c> and can still be used for
- backwards compatibility reasons.</p>
- <p></p>
+ <p>(One of <c><![CDATA[-n, -name, -sname]]></c> is required.)
+ Has the same meaning as <c><![CDATA[-name]]></c> and can still be
+ used for backward compatibility reasons.</p>
</item>
- <tag>-name Node</tag>
+ <tag><c>-name Node</c></tag>
<item>
- <p>(one of <c><![CDATA[-n, -name, -sname]]></c> is required): <c><![CDATA[Node]]></c> is the name of the node to be
+ <p>(One of <c><![CDATA[-n, -name, -sname]]></c> is required.)
+ <c><![CDATA[Node]]></c> is the name of the node to be
started or communicated with. It is assumed that
- <c><![CDATA[Node]]></c> is started with <c><![CDATA[erl -name]]></c>, which means that fully
- qualified long node names are used.
- If the <c><![CDATA[-s]]></c> option is given, an Erlang node will (if necessary)
- be started with <c><![CDATA[erl -name]]></c>.</p>
- <p></p>
+ <c><![CDATA[Node]]></c> is started with
+ <c><![CDATA[erl -name]]></c>, which means that fully
+ qualified long node names are used. If option
+ <c><![CDATA[-s]]></c> is specified, an Erlang node will (if
+ necessary) be started with <c><![CDATA[erl -name]]></c>.</p>
</item>
- <tag>-q</tag>
+ <tag><c>-q</c></tag>
<item>
- <p>(<em>optional</em>): Halts the Erlang node specified
- with the -n switch. This switch overrides the -s switch.</p>
- <p></p>
+ <p>(<em>Optional.</em>) Halts the Erlang node specified
+ with switch <c>-n</c>. This switch overrides switch <c>-s</c>.</p>
</item>
- <tag>-r</tag>
+ <tag><c>-r</c></tag>
<item>
- <p>(<em>optional</em>): Generates a random name of the hidden node
+ <p>(<em>Optional.</em>) Generates a random name of the hidden node
that <c><![CDATA[erl_call]]></c> represents.</p>
- <p></p>
</item>
- <tag>-s</tag>
+ <tag><c>-s</c></tag>
<item>
- <p>(<em>optional</em>): Starts a distributed Erlang node if necessary.
- This means that in a sequence of calls, where the '<c><![CDATA[-s]]></c>'
- and '<c><![CDATA[-n Node]]></c>' are constant, only the first call will start
- the Erlang node. This makes the rest of the communication
- very fast. This flag is currently only available on the Unix platform.</p>
- <p></p>
+ <p>(<em>Optional.</em>) Starts a distributed Erlang node if
+ necessary. This means that in a sequence of calls, where
+ '<c><![CDATA[-s]]></c>' and '<c><![CDATA[-n Node]]></c>' are
+ constant, only the first call starts the Erlang node. This makes
+ the rest of the communication very fast. This flag is currently
+ only available on Unix-like platforms (Linux, Mac OS X, Solaris,
+ and so on).</p>
</item>
- <tag>-sname Node</tag>
+ <tag><c>-sname Node</c></tag>
<item>
- <p>(one of <c><![CDATA[-n, -name, -sname]]></c> is required): <c><![CDATA[Node]]></c> is the name of the node to
- be started or communicated with. It is assumed that <c><![CDATA[Node]]></c> is started with <c><![CDATA[erl -sname]]></c> which means that short node names are used.
- If <c><![CDATA[-s]]></c> option is given, an Erlang node will be started (if necessary) with <c><![CDATA[erl -sname]]></c>.</p>
- <p></p>
+ <p>(One of <c><![CDATA[-n, -name, -sname]]></c> is required.)
+ <c><![CDATA[Node]]></c> is the name of the node to be started
+ or communicated with. It is assumed that <c><![CDATA[Node]]></c>
+ is started with <c><![CDATA[erl -sname]]></c>, which means that
+ short node names are used. If option <c><![CDATA[-s]]></c> is
+ specified, an Erlang node is started (if necessary) with
+ <c><![CDATA[erl -sname]]></c>.</p>
</item>
- <tag>-v</tag>
+ <tag><c>-v</c></tag>
<item>
- <p>(<em>optional</em>): Prints a lot of <c><![CDATA[verbose]]></c> information.
- This is only useful for the developer and maintainer of <c><![CDATA[erl_call]]></c>.</p>
- <p></p>
+ <p>(<em>Optional.</em>) Prints a lot of <c><![CDATA[verbose]]></c>
+ information. This is only useful for the developer and maintainer
+ of <c><![CDATA[erl_call]]></c>.</p>
</item>
- <tag>-x ErlScript</tag>
+ <tag><c>-x ErlScript</c></tag>
<item>
- <p>(<em>optional</em>): Specifies another name of the Erlang start-up script
- to be used. If not specified, the standard <c><![CDATA[erl]]></c> start-up script
- is used.</p>
+ <p>(<em>Optional.</em>) Specifies another name of the Erlang
+ startup script to be used. If not specified, the standard
+ <c><![CDATA[erl]]></c> startup script is used.</p>
</item>
</taglist>
</desc>
@@ -165,20 +176,29 @@
<section>
<title>Examples</title>
- <p>Starts an Erlang node and calls <c><![CDATA[erlang:time/0]]></c>.</p>
+ <p>To start an Erlang node and call <c><![CDATA[erlang:time/0]]></c>:</p>
+
<code type="none"><![CDATA[
erl_call -s -a 'erlang time' -n madonna
{18,27,34}
]]></code>
- <p>Terminates an Erlang node by calling <c><![CDATA[erlang:halt/0]]></c>.</p>
+
+ <p>To terminate an Erlang node by calling
+ <c><![CDATA[erlang:halt/0]]></c>:</p>
+
<code type="none"><![CDATA[
erl_call -s -a 'erlang halt' -n madonna
]]></code>
- <p>An apply with several arguments.</p>
+
+ <p>To apply with many arguments:</p>
+
<code type="none"><![CDATA[
erl_call -s -a 'lists map [{math,sqrt},[1,4,9,16,25]]' -n madonna
]]></code>
- <p>Evaluates a couple of expressions. <em>The input ends with EOF (Control-D)</em>.</p>
+
+ <p>To evaluate some expressions
+ (<em>the input ends with EOF (Control-D)</em>):</p>
+
<code type="none"><![CDATA[
erl_call -s -e -n madonna
statistics(runtime),
@@ -189,7 +209,11 @@ Y=2,
^D
{ok,{3,0}}
]]></code>
- <p>Compiles a module and runs it. <em>Again, the input ends with EOF (Control-D)</em>. (In the example shown, the output has been formatted afterwards).</p>
+
+ <p>To compile a module and run it (<em>again, the input ends with EOF
+ (Control-D)</em>):</p>
+ <p>(In the example, the output has been formatted afterwards.)</p>
+
<code type="none"><![CDATA[
erl_call -s -m -a lolita -n madonna
-module(lolita).
diff --git a/lib/erl_interface/doc/src/erl_connect.xml b/lib/erl_interface/doc/src/erl_connect.xml
index 0799e30905..a027cb0a84 100644
--- a/lib/erl_interface/doc/src/erl_connect.xml
+++ b/lib/erl_interface/doc/src/erl_connect.xml
@@ -28,27 +28,30 @@
<docno></docno>
<approved>Bjarne D&auml;cker</approved>
<checked>Torbj&ouml;rn T&ouml;rnkvist</checked>
- <date>980703</date>
+ <date>1998-07-03</date>
<rev>A</rev>
<file>erl_connect.xml</file>
</header>
<lib>erl_connect</lib>
- <libsummary>Communicate with Distributed Erlang</libsummary>
+ <libsummary>Communicate with distributed Erlang.</libsummary>
<description>
<p>This module provides support for communication between distributed
- Erlang nodes and C nodes, in a manner that is transparent to Erlang
+ Erlang nodes and C-nodes, in a manner that is transparent to Erlang
processes.</p>
- <p>A C node appears to Erlang as a
- <em>hidden node</em>.
+
+ <p>A C-node appears to Erlang as a <em>hidden node</em>.
That is, Erlang processes that know the name of the
- C node are able to communicate with it in a normal manner, but
- the node name will not appear in the listing provided by the
- Erlang function <c><![CDATA[nodes/0]]></c>.</p>
+ C-node can communicate with it in a normal manner, but
+ the node name does not appear in the listing provided by
+ <seealso marker="erts:erlang#nodes/0"><c>erlang:nodes/0</c></seealso>
+ in <c>ERTS</c>.</p>
</description>
+
<funcs>
<func>
<name><ret>int</ret><nametext>erl_accept(listensock, conp)</nametext></name>
<fsummary>Accept a connection.</fsummary>
+ <marker id="erl_accept"/>
<type>
<v>int listensock;</v>
<v>ErlConnect *conp;</v>
@@ -56,10 +59,12 @@
<desc>
<p>This function is used by a server process to accept a
connection from a client process.</p>
- <p><c><![CDATA[listensock]]></c> is an open socket descriptor on which
- <c><![CDATA[listen()]]></c> has previously been called.</p>
- <p><c><![CDATA[conp]]></c> is a pointer to an <c><![CDATA[ErlConnect]]></c> struct,
- described as follows:</p>
+ <list type="bulleted">
+ <item><c><![CDATA[listensock]]></c> is an open socket descriptor on
+ which <c><![CDATA[listen()]]></c> has previously been called.</item>
+ <item><c><![CDATA[conp]]></c> is a pointer to an
+ <c><![CDATA[ErlConnect]]></c> struct, described as follows:</item>
+ </list>
<code type="none"><![CDATA[
typedef struct {
char ipadr[4];
@@ -72,6 +77,7 @@ typedef struct {
<c><![CDATA[erl_errno]]></c> is set to <c><![CDATA[EIO]]></c>.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>erl_close_connection(fd)</nametext></name>
<fsummary>Close a connection to an Erlang node.</fsummary>
@@ -79,47 +85,54 @@ typedef struct {
<v>int fd;</v>
</type>
<desc>
- <p>This function closes an open connection to an Erlang node.</p>
+ <p>Closes an open connection to an Erlang node.</p>
<p><c><![CDATA[Fd]]></c> is a file descriptor obtained from
- <c><![CDATA[erl_connect()]]></c> or <c><![CDATA[erl_xconnect()]]></c>.</p>
- <p>On success, 0 is returned. If the call fails, a non-zero value
- is returned, and the reason for
- the error can be obtained with the appropriate platform-dependent
- call.</p>
+ <c><![CDATA[erl_connect()]]></c> or
+ <c><![CDATA[erl_xconnect()]]></c>.</p>
+ <p>Returns <c>0</c> on success. If the call fails, a non-zero value
+ is returned, and the reason for the error can be obtained with the
+ appropriate platform-dependent call.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>erl_connect(node)</nametext></name>
<name><ret>int</ret><nametext>erl_xconnect(addr, alive)</nametext></name>
- <fsummary>Establishe a connection to an Erlang node.</fsummary>
+ <fsummary>Establish a connection to an Erlang node.</fsummary>
<type>
<v>char *node, *alive;</v>
<v>struct in_addr *addr;</v>
</type>
<desc>
- <p>These functions set up a connection to an Erlang node.</p>
- <p><c><![CDATA[erl_xconnect()]]></c> requires the IP address of the remote
- host and the alive name of the remote node
- to be specified. <c><![CDATA[erl_connect()]]></c> provides an alternative
+ <p>Sets up a connection to an Erlang node.</p>
+ <p><c><![CDATA[erl_xconnect()]]></c> requires the IP address of the
+ remote host and the alivename of the remote node to be
+ specified. <c><![CDATA[erl_connect()]]></c> provides an alternative
interface, and determines the information from the node name
provided.</p>
- <p><c><![CDATA[addr]]></c> is the 32-bit IP address of the remote host.</p>
- <p><c><![CDATA[alive]]></c> is the alivename of the remote node.</p>
- <p><c><![CDATA[node]]></c> is the name of the remote node.</p>
- <p>These functions return an open file descriptor on success, or
- a negative value indicating that an error occurred --- in
- which case they will set <c><![CDATA[erl_errno]]></c> to one of:</p>
+ <list type="bulleted">
+ <item><c><![CDATA[addr]]></c> is the 32-bit IP address of the remote
+ host.</item>
+ <item><c><![CDATA[alive]]></c> is the alivename of the remote node.
+ </item>
+ <item><c><![CDATA[node]]></c> is the name of the remote node.</item>
+ </list>
+ <p>Returns an open file descriptor on success, otherwise a negative
+ value. In the latter case <c><![CDATA[erl_errno]]></c> is set to one
+ of:</p>
<taglist>
<tag><c><![CDATA[EHOSTUNREACH]]></c></tag>
- <item>The remote host <c><![CDATA[node]]></c> is unreachable</item>
+ <item>The remote host <c><![CDATA[node]]></c> is unreachable.</item>
<tag><c><![CDATA[ENOMEM]]></c></tag>
- <item>No more memory available.</item>
+ <item>No more memory is available.</item>
<tag><c><![CDATA[EIO]]></c></tag>
<item>I/O error.</item>
</taglist>
- <p>Additionally, <c><![CDATA[errno]]></c> values from
- <c><![CDATA[socket]]></c><em>(2)</em> and <c><![CDATA[connect]]></c><em>(2)</em>
- system calls may be propagated into <c><![CDATA[erl_errno]]></c>.</p>
+ <p>Also, <c><![CDATA[errno]]></c> values from
+ <c><![CDATA[socket]]></c><em>(2)</em> and
+ <c><![CDATA[connect]]></c><em>(2)</em>
+ system calls can be propagated into <c><![CDATA[erl_errno]]></c>.</p>
+ <p><em>Example:</em></p>
<code type="none"><![CDATA[
#define NODE "[email protected]"
#define ALIVE "madonna"
@@ -135,10 +148,12 @@ erl_xconnect( &addr , ALIVE );
]]></code>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>erl_connect_init(number, cookie, creation)</nametext></name>
<name><ret>int</ret><nametext>erl_connect_xinit(host, alive, node, addr, cookie, creation)</nametext></name>
<fsummary>Initialize communication.</fsummary>
+ <marker id="erl_connect_init"/>
<type>
<v>int number;</v>
<v>char *cookie;</v>
@@ -147,47 +162,72 @@ erl_xconnect( &addr , ALIVE );
<v>struct in_addr *addr;</v>
</type>
<desc>
- <p>These functions initialize the <c><![CDATA[erl_connect]]></c>
- module. In particular, they are used to identify the name of the
+ <p>Initializes the <c><![CDATA[erl_connect]]></c> module.
+ In particular, these functions are used to identify the name of the
C-node from which they are called. One of these functions must
- be called before any of the other functions in the erl_connect
+ be called before any of the other functions in the <c>erl_connect</c>
module are used.</p>
- <p><c><![CDATA[erl_connect_xinit()]]></c> stores for later use information about
- the node's host name <c><![CDATA[host]]></c>, alive name <c><![CDATA[alive]]></c>, node
- name <c><![CDATA[node]]></c>, IP address <c><![CDATA[addr]]></c>, cookie <c><![CDATA[cookie]]></c>,
- and creation number <c><![CDATA[creation]]></c>. <c><![CDATA[erl_connect_init()]]></c>
- provides an alternative interface which does not require as much
- information from the caller. Instead, <c><![CDATA[erl_connect_init()]]></c>
- uses <c><![CDATA[gethostbyname()]]></c> to obtain default values.
- </p>
- <p>If you use <c><![CDATA[erl_connect_init()]]></c> your node will have a
- short name, i.e., it will not be fully qualified. If you need to
- use fully qualified (a.k.a. long) names, use
- <c><![CDATA[erl_connect_xinit()]]></c> instead.
- </p>
- <p><c><![CDATA[host]]></c> is the name of the host on which the node is running.</p>
- <p><c><![CDATA[alive]]></c> is the alivename of the node.</p>
- <p><c><![CDATA[node]]></c> is the name of the node. The nodename should
- be of the form <em>alivename@hostname</em>.</p>
- <p><c><![CDATA[addr]]></c> is the 32-bit IP address of <c><![CDATA[host]]></c>.</p>
- <p><c><![CDATA[cookie]]></c> is the authorization string required for access
- to the remote node. If NULL the user HOME directory is
- searched for a cookie file <c><![CDATA[.erlang.cookie]]></c>. The path to
- the home directory is retrieved from the environment variable
- <c><![CDATA[HOME]]></c> on Unix and from the <c><![CDATA[HOMEDRIVE]]></c> and
- <c><![CDATA[HOMEPATH]]></c> variables on Windows. Refer to the <c><![CDATA[auth]]></c>
- module for more details.</p>
- <p><c><![CDATA[creation]]></c> helps identify a particular instance of a C
- node. In particular, it can help prevent us from receiving
- messages sent to an earlier process with the same registered
- name.</p>
- <p>A C node acting as a server will be assigned a creation number
+ <p><c><![CDATA[erl_connect_xinit()]]></c> stores for later use
+ information about:</p>
+ <list type="bulleted">
+ <item>Hostname of the node, <c><![CDATA[host]]></c></item>
+ <item>Alivename, <c><![CDATA[alive]]></c></item>
+ <item>Node name, <c><![CDATA[node]]></c></item>
+ <item>IP address, <c><![CDATA[addr]]></c></item>
+ <item>Cookie, <c><![CDATA[cookie]]></c></item>
+ <item>Creation number, <c><![CDATA[creation]]></c></item>
+ </list>
+ <p><c><![CDATA[erl_connect_init()]]></c>
+ provides an alternative interface that does not require as much
+ information from the caller. Instead,
+ <c><![CDATA[erl_connect_init()]]></c>
+ uses <c><![CDATA[gethostbyname()]]></c> to obtain default values.</p>
+ <p>If you use <c><![CDATA[erl_connect_init()]]></c>, your node will
+ have a short name, that is, it will not be fully qualified. If you
+ need to use fully qualified (long) names, use
+ <c><![CDATA[erl_connect_xinit()]]></c> instead.</p>
+ <list type="bulleted">
+ <item>
+ <p><c><![CDATA[host]]></c> is the name of the host on which the node
+ is running.</p>
+ </item>
+ <item>
+ <p><c><![CDATA[alive]]></c> is the alivename of the node.</p>
+ </item>
+ <item>
+ <p><c><![CDATA[node]]></c> is the node name. It is to
+ be of the form <em>alivename@hostname</em>.</p>
+ </item>
+ <item>
+ <p><c><![CDATA[addr]]></c> is the 32-bit IP address of
+ <c><![CDATA[host]]></c>.</p>
+ </item>
+ <item>
+ <p><c><![CDATA[cookie]]></c> is the authorization string required
+ for access to the remote node. If <c>NULL</c>, the user
+ <c>HOME</c> directory is searched for a cookie file
+ <c><![CDATA[.erlang.cookie]]></c>. The path to
+ the home directory is retrieved from environment variable
+ <c><![CDATA[HOME]]></c> on Unix and from the
+ <c><![CDATA[HOMEDRIVE]]></c> and
+ <c><![CDATA[HOMEPATH]]></c> variables on Windows. For more
+ details, see the <seealso marker="kernel:auth">
+ <c>kernel:auth</c></seealso> module.</p>
+ </item>
+ <item>
+ <p><c><![CDATA[creation]]></c> helps identifying a particular
+ instance of a C-node. In particular, it can help prevent us from
+ receiving messages sent to an earlier process with the same
+ registered name.</p>
+ </item>
+ </list>
+ <p>A C-node acting as a server is assigned a creation number
when it calls <c><![CDATA[erl_publish()]]></c>.</p>
- <p><c><![CDATA[number]]></c> is used by <c><![CDATA[erl_connect_init()]]></c> to
- construct the actual node name. In the second example shown
- below, <em>"[email protected]"</em> will be the resulting node
- name.</p>
- <p>Example 1:</p>
+ <p><c><![CDATA[number]]></c> is used by
+ <c><![CDATA[erl_connect_init()]]></c> to
+ construct the actual node name. In Example 2
+ below, <em>"[email protected]"</em> is the resulting node name.</p>
+ <p><em>Example 1:</em></p>
<code type="none"><![CDATA[
struct in_addr addr;
addr = inet_addr("150.236.14.75");
@@ -199,13 +239,14 @@ if (!erl_connect_xinit("chivas",
0)
erl_err_quit("<ERROR> when initializing !");
]]></code>
- <p>Example 2:</p>
+ <p><em>Example 2:</em></p>
<code type="none"><![CDATA[
if (!erl_connect_init(17, "samplecookiestring...", 0))
erl_err_quit("<ERROR> when initializing !");
]]></code>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>erl_publish(port)</nametext></name>
<fsummary>Publish a node name.</fsummary>
@@ -213,66 +254,74 @@ if (!erl_connect_init(17, "samplecookiestring...", 0))
<v>int port;</v>
</type>
<desc>
- <p>These functions are used by a server process to register
+ <p>This function is used by a server process to register
with the local name server <em>epmd</em>, thereby allowing
other processes to send messages by using the registered name.
- Before calling either of these functions, the process should
- have called <c><![CDATA[bind()]]></c> and <c><![CDATA[listen()]]></c> on an open socket.</p>
- <p><c><![CDATA[port]]></c> is the local name to register, and should be the
- same as the port number that was previously bound to the socket.</p>
- <p>To unregister with epmd, simply close the returned
- descriptor.
- </p>
- <p>On success, the functions return a descriptor connecting the
- calling process to epmd. On failure, they return -1 and set
- <c><![CDATA[erl_errno]]></c> to:</p>
+ Before calling this function, the process should
+ have called <c><![CDATA[bind()]]></c> and <c><![CDATA[listen()]]></c>
+ on an open socket.</p>
+ <p><c><![CDATA[port]]></c> is the local name to register, and is to be
+ the same as the port number that was previously bound to the
+ socket.</p>
+ <p>To unregister with EPMD, simply close the returned descriptor.</p>
+ <p>On success, a descriptor connecting the calling process to EPMD is
+ returned. On failure, <c>-1</c> is returned and
+ <c><![CDATA[erl_errno]]></c> is set to:</p>
<taglist>
<tag><c><![CDATA[EIO]]></c></tag>
- <item>I/O error</item>
+ <item>I/O error.</item>
</taglist>
- <p>Additionally, <c><![CDATA[errno]]></c> values from <c><![CDATA[socket]]></c><em>(2)</em>
- and <c><![CDATA[connect]]></c><em>(2)</em> system calls may be propagated
- into <c><![CDATA[erl_errno]]></c>.
- </p>
+ <p>Also, <c><![CDATA[errno]]></c> values from
+ <c><![CDATA[socket]]></c><em>(2)</em>
+ and <c><![CDATA[connect]]></c><em>(2)</em> system calls can be
+ propagated into <c><![CDATA[erl_errno]]></c>.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>erl_receive(fd, bufp, bufsize)</nametext></name>
<fsummary>Receive a message.</fsummary>
+ <marker id="erl_receive"/>
<type>
<v>int fd;</v>
<v>char *bufp;</v>
<v>int bufsize;</v>
</type>
<desc>
- <p>This function receives a message consisting of a sequence
+ <p>Receives a message consisting of a sequence
of bytes in the Erlang external format.</p>
- <p><c><![CDATA[fd]]></c> is an open descriptor to an Erlang connection.</p>
- <p><c><![CDATA[bufp]]></c> is a buffer large enough to hold the expected
- message. </p>
- <p><c><![CDATA[bufsize]]></c> indicates the size of <c><![CDATA[bufp]]></c>.</p>
- <p>If a <em>tick</em> occurs, i.e., the Erlang node on the
+ <list type="bulleted">
+ <item><c><![CDATA[fd]]></c> is an open descriptor to an Erlang
+ connection.</item>
+ <item><c><![CDATA[bufp]]></c> is a buffer large enough to hold the
+ expected message.</item>
+ <item><c><![CDATA[bufsize]]></c> indicates the size of
+ <c><![CDATA[bufp]]></c>.</item>
+ </list>
+ <p>If a <em>tick</em> occurs, that is, the Erlang node on the
other end of the connection has polled this node to see if it
- is still alive, the function will return <c><![CDATA[ERL_TICK]]></c> and
- no message will be placed in the buffer. Also,
- <c><![CDATA[erl_errno]]></c> will be set to <c><![CDATA[EAGAIN]]></c>.</p>
+ is still alive, the function returns <c><![CDATA[ERL_TICK]]></c> and
+ no message is placed in the buffer. Also,
+ <c><![CDATA[erl_errno]]></c> is set to <c><![CDATA[EAGAIN]]></c>.</p>
<p>On success, the message is placed in the specified buffer
and the function returns the number of bytes actually read. On
- failure, the function returns a negative value and will set
+ failure, the function returns a negative value and sets
<c><![CDATA[erl_errno]]></c> to one of:</p>
<taglist>
<tag><c><![CDATA[EAGAIN]]></c></tag>
<item>Temporary error: Try again.</item>
<tag><c><![CDATA[EMSGSIZE]]></c></tag>
- <item>Buffer too small.</item>
+ <item>Buffer is too small.</item>
<tag><c><![CDATA[EIO]]></c></tag>
<item>I/O error.</item>
</taglist>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>erl_receive_msg(fd, bufp, bufsize, emsg)</nametext></name>
- <fsummary>Receive and decodes a message.</fsummary>
+ <fsummary>Receive and decode a message.</fsummary>
+ <marker id="erl_receive_msg"/>
<type>
<v>int fd;</v>
<v>unsigned char *bufp;</v>
@@ -280,14 +329,20 @@ if (!erl_connect_init(17, "samplecookiestring...", 0))
<v>ErlMessage *emsg;</v>
</type>
<desc>
- <p>This function receives the message into the specified buffer,
- and decodes into the <c><![CDATA[(ErlMessage *) emsg]]></c>.</p>
- <p><c><![CDATA[fd]]></c> is an open descriptor to an Erlang connection.</p>
- <p><c><![CDATA[bufp]]></c> is a buffer large enough to hold the expected message.</p>
- <p><c><![CDATA[bufsize]]></c> indicates the size of <c><![CDATA[bufp]]></c>.</p>
- <p><c><![CDATA[emsg]]></c> is a pointer to an <c><![CDATA[ErlMessage]]></c> structure,
- into which the message will be decoded. <c><![CDATA[ErlMessage]]></c> is
- defined as follows:</p>
+ <p>Receives the message into the specified buffer
+ and decodes into <c><![CDATA[(ErlMessage *) emsg]]></c>.</p>
+ <list type="bulleted">
+ <item><c><![CDATA[fd]]></c> is an open descriptor to an Erlang
+ connection.</item>
+ <item><c><![CDATA[bufp]]></c> is a buffer large enough to hold the
+ expected message.</item>
+ <item><c><![CDATA[bufsize]]></c> indicates the size of
+ <c><![CDATA[bufp]]></c>.</item>
+ <item>><c><![CDATA[emsg]]></c> is a pointer to an
+ <c><![CDATA[ErlMessage]]></c> structure
+ into which the message will be decoded.
+ <c><![CDATA[ErlMessage]]></c> is defined as follows:</item>
+ </list>
<code type="none"><![CDATA[
typedef struct {
int type;
@@ -299,81 +354,95 @@ typedef struct {
]]></code>
<note>
<p>The definition of <c><![CDATA[ErlMessage]]></c> has changed since
- earlier versions of Erl_Interface.</p>
+ earlier versions of <c>Erl_Interface</c>.</p>
</note>
- <p><c><![CDATA[type]]></c> identifies the type of message, one of
- <c><![CDATA[ERL_SEND]]></c>, <c><![CDATA[ERL_REG_SEND]]></c>, <c><![CDATA[ERL_LINK]]></c>,
- <c><![CDATA[ERL_UNLINK]]></c> and <c><![CDATA[ERL_EXIT]]></c>.
- </p>
- <p>If <c><![CDATA[type]]></c> contains <c><![CDATA[ERL_SEND]]></c>
- this indicates that an ordinary send operation has taken
- place, and <c><![CDATA[emsg->to]]></c> contains the Pid of the
- recipient. If <c><![CDATA[type]]></c> contains <c><![CDATA[ERL_REG_SEND]]></c> then a
- registered send operation took place, and <c><![CDATA[emsg->from]]></c>
- contains the Pid of the sender. In both cases, the actual
- message will be in <c><![CDATA[emsg->msg]]></c>.
- </p>
- <p>If <c><![CDATA[type]]></c> contains one of <c><![CDATA[ERL_LINK]]></c> or
- <c><![CDATA[ERL_UNLINK]]></c>, then <c><![CDATA[emsg->to]]></c> and <c><![CDATA[emsg->from]]></c>
- contain the pids of the sender and recipient of the link or unlink.
- <c><![CDATA[emsg->msg]]></c> is not used in these cases.
- </p>
- <p>If <c><![CDATA[type]]></c> contains <c><![CDATA[ERL_EXIT]]></c>, then this
- indicates that a link has been broken. In this case,
- <c><![CDATA[emsg->to]]></c> and <c><![CDATA[emsg->from]]></c> contain the pids of the
- linked processes, and <c><![CDATA[emsg->msg]]></c> contains the reason for
- the exit.
- </p>
+ <p><c><![CDATA[type]]></c> identifies the type of message, one of the
+ following:</p>
+ <taglist>
+ <tag><c><![CDATA[ERL_SEND]]></c></tag>
+ <item>
+ <p>An ordinary send operation has occurred and
+ <c><![CDATA[emsg->to]]></c> contains the pid of the recipient.
+ The message is in <c><![CDATA[emsg->msg]]></c>.</p>
+ </item>
+ <tag><c><![CDATA[ERL_REG_SEND]]></c></tag>
+ <item>
+ <p>A registered send operation has occurred and
+ <c><![CDATA[emsg->from]]></c> contains the pid of the sender.
+ The message is in <c><![CDATA[emsg->msg]]></c>.</p>
+ </item>
+ <tag><c><![CDATA[ERL_LINK]]></c> or <c><![CDATA[ERL_UNLINK]]></c>
+ </tag>
+ <item>
+ <p><c><![CDATA[emsg->to]]></c> and <c><![CDATA[emsg->from]]></c>
+ contain the pids of the sender and recipient of the link or
+ unlink. <c><![CDATA[emsg->msg]]></c> is not used.</p>
+ </item>
+ <tag><c><![CDATA[ERL_EXIT]]></c></tag>
+ <item>
+ <p>A link is broken. <c><![CDATA[emsg->to]]></c> and
+ <c><![CDATA[emsg->from]]></c> contain the pids of the linked
+ processes, and <c><![CDATA[emsg->msg]]></c> contains the reason
+ for the exit.</p>
+ </item>
+ </taglist>
<note>
<p>It is the caller's responsibility to release the
- memory pointed to by <c><![CDATA[emsg->msg]]></c>, <c><![CDATA[emsg->to]]></c> and
+ memory pointed to by <c><![CDATA[emsg->msg]]></c>,
+ <c><![CDATA[emsg->to]]></c>, and
<c><![CDATA[emsg->from]]></c>.</p>
</note>
- <p>If a <em>tick</em> occurs, i.e., the Erlang node on the
+ <p>If a <em>tick</em> occurs, that is, the Erlang node on the
other end of the connection has polled this node to see if it
- is still alive, the function will return <c><![CDATA[ERL_TICK]]></c>
+ is still alive, the function returns <c><![CDATA[ERL_TICK]]></c>
indicating that the tick has been received and responded to,
- but no message will be placed in the buffer. In this case you
- should call <c><![CDATA[erl_receive_msg()]]></c> again.</p>
+ but no message is placed in the buffer. In this case you
+ are to call <c><![CDATA[erl_receive_msg()]]></c> again.</p>
<p>On success, the function returns <c><![CDATA[ERL_MSG]]></c> and the
- <c><![CDATA[Emsg]]></c> struct will be initialized as described above, or
+ <c><![CDATA[Emsg]]></c> struct is initialized as described above, or
<c><![CDATA[ERL_TICK]]></c>, in which case no message is returned. On
- failure, the function returns <c><![CDATA[ERL_ERROR]]></c> and will set
+ failure, the function returns <c><![CDATA[ERL_ERROR]]></c> and sets
<c><![CDATA[erl_errno]]></c> to one of:</p>
<taglist>
<tag><c><![CDATA[EMSGSIZE]]></c></tag>
- <item>Buffer too small.</item>
+ <item>Buffer is too small.</item>
<tag><c><![CDATA[ENOMEM]]></c></tag>
- <item>No more memory available.</item>
+ <item>No more memory is available.</item>
<tag><c><![CDATA[EIO]]></c></tag>
<item>I/O error.</item>
</taglist>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>erl_reg_send(fd, to, msg)</nametext></name>
<fsummary>Send a message to a registered name.</fsummary>
+ <marker id="erl_reg_send"/>
<type>
<v>int fd;</v>
<v>char *to;</v>
<v>ETERM *msg;</v>
</type>
<desc>
- <p>This function sends an Erlang term to a registered process.</p>
- <p><c><![CDATA[fd]]></c> is an open descriptor to an Erlang connection.</p>
- <p><c><![CDATA[to]]></c> is a string containing the registered name of
- the intended recipient of the message.</p>
- <p><c><![CDATA[msg]]></c> is the Erlang term to be sent.</p>
- <p>The function returns 1 if successful, otherwise 0 --- in
- which case it will set <c><![CDATA[erl_errno]]></c> to one of:</p>
+ <p>Sends an Erlang term to a registered process.</p>
+ <list type="bulleted">
+ <item><c><![CDATA[fd]]></c> is an open descriptor to an Erlang
+ connection.</item>
+ <item><c><![CDATA[to]]></c> is a string containing the registered name
+ of the intended recipient of the message.</item>
+ <item><c><![CDATA[msg]]></c> is the Erlang term to be sent.</item>
+ </list>
+ <p>Returns <c>1</c> on success, otherwise <c>0</c>. In
+ the latter case <c><![CDATA[erl_errno]]></c> is set to one of:</p>
<taglist>
<tag><c><![CDATA[ENOMEM]]></c></tag>
- <item>No more memory available.</item>
+ <item>No more memory is available.</item>
<tag><c><![CDATA[EIO]]></c></tag>
<item>I/O error.</item>
</taglist>
</desc>
</func>
+
<func>
<name><ret>ETERM *</ret><nametext>erl_rpc(fd, mod, fun, args)</nametext></name>
<name><ret>int</ret><nametext>erl_rpc_from(fd, timeout, emsg)</nametext></name>
@@ -386,81 +455,97 @@ typedef struct {
<v>ErlMessage *emsg;</v>
</type>
<desc>
- <p>These functions support calling Erlang functions on remote nodes.
- <c><![CDATA[erl_rpc_to()]]></c> sends an rpc request to a remote node and
- <c><![CDATA[erl_rpc_from()]]></c> receives the results of such a call.
- <c><![CDATA[erl_rpc()]]></c> combines the functionality of these two functions
- by sending an rpc request and waiting for the results. See also
- <c><![CDATA[rpc:call/4]]></c>. </p>
- <p><c><![CDATA[fd]]></c> is an open descriptor to an Erlang connection.</p>
- <p><c><![CDATA[timeout]]></c> is the maximum time (in ms) to wait for
- results. Specify <c><![CDATA[ERL_NO_TIMEOUT]]></c> to wait forever.
- When erl_rpc() calls erl_rpc_from(), the call will never
- timeout.</p>
- <p><c><![CDATA[mod]]></c> is the name of the module containing the function
- to be run on the remote node.</p>
- <p><c><![CDATA[fun]]></c> is the name of the function to run.</p>
- <p><c><![CDATA[args]]></c> is an Erlang list, containing the arguments to be
- passed to the function. </p>
- <p><c><![CDATA[emsg]]></c> is a message containing the result of the
- function call.</p>
- <p>The actual message returned by the rpc server
- is a 2-tuple <c><![CDATA[{rex,Reply}]]></c>. If you are using
- <c><![CDATA[erl_rpc_from()]]></c> in your code then this is the message you
- will need to parse. If you are using <c><![CDATA[erl_rpc()]]></c> then the
+ <p>Supports calling Erlang functions on remote nodes.
+ <c><![CDATA[erl_rpc_to()]]></c> sends an RPC request to a remote node
+ and <c><![CDATA[erl_rpc_from()]]></c> receives the results of such a
+ call. <c><![CDATA[erl_rpc()]]></c> combines the functionality of
+ these two functions by sending an RPC request and waiting for the
+ results. See also <seealso marker="kernel:rpc#call/4">
+ <c>rpc:call/4</c></seealso> in <c>Kernel</c>.</p>
+ <list type="bulleted">
+ <item><c><![CDATA[fd]]></c> is an open descriptor to an Erlang
+ connection.</item>
+ <item><c><![CDATA[timeout]]></c> is the maximum time (in milliseconds)
+ to wait for
+ results. To wait forever, specify <c><![CDATA[ERL_NO_TIMEOUT]]></c>.
+ When <c>erl_rpc()</c> calls <c>erl_rpc_from()</c>, the call will
+ never timeout.</item>
+ <item><c><![CDATA[mod]]></c> is the name of the module containing the
+ function to be run on the remote node.</item>
+ <item><c><![CDATA[fun]]></c> is the name of the function to run.
+ </item>
+ <item><c><![CDATA[args]]></c> is an Erlang list, containing the
+ arguments to be passed to the function.</item>
+ <item><c><![CDATA[emsg]]></c> is a message containing the result of
+ the function call.</item>
+ </list>
+ <p>The actual message returned by the RPC server
+ is a 2-tuple <c><![CDATA[{rex,Reply}]]></c>. If you use
+ <c><![CDATA[erl_rpc_from()]]></c> in your code, this is the message
+ you will need to parse. If you use <c><![CDATA[erl_rpc()]]></c>, the
tuple itself is parsed for you, and the message returned to your
- program is the erlang term containing <c><![CDATA[Reply]]></c> only. Replies
- to rpc requests are always ERL_SEND messages.
- </p>
+ program is the Erlang term containing <c><![CDATA[Reply]]></c> only.
+ Replies to RPC requests are always <c>ERL_SEND</c> messages.</p>
<note>
<p>It is the caller's responsibility to free the returned
- <c><![CDATA[ETERM]]></c> structure as well as the memory pointed to by
- <c><![CDATA[emsg->msg]]></c> and <c><![CDATA[emsg->to]]></c>. </p>
+ <c><![CDATA[ETERM]]></c> structure and the memory pointed to by
+ <c><![CDATA[emsg->msg]]></c> and <c><![CDATA[emsg->to]]></c>.</p>
</note>
- <p><c><![CDATA[erl_rpc()]]></c> returns the remote function's return value (or
- <c><![CDATA[NULL]]></c> if it failed). <c><![CDATA[erl_rpc_to()]]></c> returns 0 on
- success, and a negative number on failure. <c><![CDATA[erl_rcp_from()]]></c>
- returns <c><![CDATA[ERL_MSG]]></c> when successful (with <c><![CDATA[Emsg]]></c> now
- containing the reply tuple), and one of <c><![CDATA[ERL_TICK]]></c>,
- <c><![CDATA[ERL_TIMEOUT]]></c> and <c><![CDATA[ERL_ERROR]]></c> otherwise. When failing,
+ <p><c><![CDATA[erl_rpc()]]></c> returns the remote function's return
+ value on success, otherwise <c><![CDATA[NULL]]></c>.</p>
+ <p><c><![CDATA[erl_rpc_to()]]></c> returns <c>0</c> on
+ success, otherwise a negative number.</p>
+ <p><c><![CDATA[erl_rcp_from()]]></c> returns <c><![CDATA[ERL_MSG]]></c>
+ on success (with <c><![CDATA[Emsg]]></c> now
+ containing the reply tuple), otherwise one of
+ <c><![CDATA[ERL_TICK]]></c>, <c><![CDATA[ERL_TIMEOUT]]></c>, or
+ <c><![CDATA[ERL_ERROR]]></c>.</p>
+ <p>When failing,
all three functions set <c><![CDATA[erl_errno]]></c> to one of:</p>
<taglist>
<tag><c><![CDATA[ENOMEM]]></c></tag>
- <item>No more memory available.</item>
+ <item>No more memory is available.</item>
<tag><c><![CDATA[EIO]]></c></tag>
<item>I/O error.</item>
<tag><c><![CDATA[ETIMEDOUT]]></c></tag>
- <item>Timeout expired.</item>
+ <item>Timeout has expired.</item>
<tag><c><![CDATA[EAGAIN]]></c></tag>
<item>Temporary error: Try again.</item>
</taglist>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>erl_send(fd, to, msg)</nametext></name>
<fsummary>Send a message.</fsummary>
+ <marker id="erl_send"/>
<type>
<v>int fd;</v>
<v>ETERM *to, *msg;</v>
</type>
<desc>
- <p>This function sends an Erlang term to a process.</p>
- <p><c><![CDATA[fd]]></c> is an open descriptor to an Erlang connection.</p>
- <p><c><![CDATA[to]]></c> is an Erlang term containing the Pid of the
- intended recipient of the message.</p>
- <p><c><![CDATA[msg]]></c> is the Erlang term to be sent.</p>
- <p>The function returns 1 if successful, otherwise 0 --- in
- which case it will set <c><![CDATA[erl_errno]]></c> to one of:</p>
+ <p>Sends an Erlang term to a process.</p>
+ <list type="bulleted">
+ <item><c><![CDATA[fd]]></c> is an open descriptor to an Erlang
+ connection.</item>
+ <item><c><![CDATA[to]]></c> is an Erlang term containing the pid of
+ the intended recipient of the message.</item>
+ <item>><c><![CDATA[msg]]></c> is the Erlang term to be sent.</item>
+ </list>
+ <p>Returns <c>1</c> on success, otherwise <c>0</c>. In
+ the latter case <c><![CDATA[erl_errno]]></c> is set to one of:</p>
<taglist>
<tag><c><![CDATA[EINVAL]]></c></tag>
- <item>Invalid argument: <c><![CDATA[to]]></c> is not a valid Erlang pid.</item>
+ <item>Invalid argument: <c><![CDATA[to]]></c> is not a valid Erlang
+ pid.</item>
<tag><c><![CDATA[ENOMEM]]></c></tag>
- <item>No more memory available.</item>
+ <item>No more memory is available.</item>
<tag><c><![CDATA[EIO]]></c></tag>
<item>I/O error.</item>
</taglist>
</desc>
</func>
+
<func>
<name><ret>const char *</ret><nametext>erl_thisalivename()</nametext></name>
<name><ret>const char *</ret><nametext>erl_thiscookie()</nametext></name>
@@ -469,11 +554,13 @@ typedef struct {
<name><ret>const char *</ret><nametext>erl_thisnodename()</nametext></name>
<fsummary>Retrieve some values.</fsummary>
<desc>
- <p>These functions can be used to retrieve information about
- the C Node. These values are initially set with
- <c><![CDATA[erl_connect_init()]]></c> or <c><![CDATA[erl_connect_xinit()]]></c>.</p>
+ <p>Retrieves information about
+ the C-node. These values are initially set with
+ <c><![CDATA[erl_connect_init()]]></c> or
+ <c><![CDATA[erl_connect_xinit()]]></c>.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>erl_unpublish(alive)</nametext></name>
<fsummary>Forcefully unpublish a node name.</fsummary>
@@ -482,28 +569,28 @@ typedef struct {
</type>
<desc>
<p>This function can be called by a process to unregister a
- specified node from epmd on the localhost. This is however usually not
- allowed, unless epmd was started with the -relaxed_command_check
- flag, which it normally isn't.</p>
-
- <p>To unregister a node you have published, you should instead
- close the descriptor that was returned by
- <c><![CDATA[ei_publish()]]></c>.</p>
-
+ specified node from EPMD on the local host. This is, however, usually
+ not allowed, unless EPMD was started with flag
+ <c>-relaxed_command_check</c>, which it normally is not.</p>
+ <p>To unregister a node you have published, you should instead
+ close the descriptor that was returned by
+ <c><![CDATA[ei_publish()]]></c>.</p>
<warning>
<p>This function is deprecated and will be removed in a future
- release.</p>
+ release.</p>
</warning>
- <p><c><![CDATA[alive]]></c> is the name of the node to unregister, i.e., the
- first component of the nodename, without the <c><![CDATA[@hostname]]></c>.</p>
- <p>If the node was successfully unregistered from epmd, the
- function returns 0. Otherwise, it returns -1 and sets
- <c><![CDATA[erl_errno]]></c> is to <c><![CDATA[EIO]]></c>.</p>
+ <p><c><![CDATA[alive]]></c> is the name of the node to unregister, that
+ is, the first component of the node name, without
+ <c><![CDATA[@hostname]]></c>.</p>
+ <p>If the node was successfully unregistered from EPMD, <c>0</c> is
+ returned, otherwise <c>-1</c> is returned and
+ <c><![CDATA[erl_errno]]></c> is set to <c><![CDATA[EIO]]></c>.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>erl_xreceive_msg(fd, bufpp, bufsizep, emsg)</nametext></name>
- <fsummary>Receive and decodes a message.</fsummary>
+ <fsummary>Receive and decode a message.</fsummary>
<type>
<v>int fd;</v>
<v>unsigned char **bufpp;</v>
@@ -511,33 +598,35 @@ typedef struct {
<v>ErlMessage *emsg;</v>
</type>
<desc>
- <p>This function is similar to <c><![CDATA[erl_receive_msg]]></c>. The
- difference is that <c><![CDATA[erl_xreceive_msg]]></c> expects the buffer to
- have been allocated by <c><![CDATA[malloc]]></c>, and reallocates it if the received
- message does not fit into the original buffer. For that reason,
- both buffer and buffer length are given as pointers - their values
- may change by the call.
- </p>
+ <p>Similar to <c><![CDATA[erl_receive_msg]]></c>. The difference is
+ that <c><![CDATA[erl_xreceive_msg]]></c> expects the buffer to
+ have been allocated by <c><![CDATA[malloc]]></c>, and reallocates it
+ if the received
+ message does not fit into the original buffer. Therefore
+ both buffer and buffer length are given as pointers; their values
+ can change by the call.</p>
<p>On success, the function returns <c><![CDATA[ERL_MSG]]></c> and the
- <c><![CDATA[Emsg]]></c> struct will be initialized as described above, or
+ <c><![CDATA[Emsg]]></c> struct is initialized as described above, or
<c><![CDATA[ERL_TICK]]></c>, in which case no message is returned. On
- failure, the function returns <c><![CDATA[ERL_ERROR]]></c> and will set
+ failure, the function returns <c><![CDATA[ERL_ERROR]]></c> and sets
<c><![CDATA[erl_errno]]></c> to one of:</p>
<taglist>
<tag><c><![CDATA[EMSGSIZE]]></c></tag>
- <item>Buffer too small.</item>
+ <item>Buffer is too small.</item>
<tag><c><![CDATA[ENOMEM]]></c></tag>
- <item>No more memory available.</item>
+ <item>No more memory is available.</item>
<tag><c><![CDATA[EIO]]></c></tag>
<item>I/O error.</item>
</taglist>
</desc>
</func>
+
<func>
<name><ret>struct hostent</ret><nametext>*erl_gethostbyaddr(addr, length, type)</nametext></name>
<name><ret>struct hostent</ret><nametext>*erl_gethostbyaddr_r(addr, length, type, hostp, buffer, buflen, h_errnop)</nametext></name>
<name><ret>struct hostent</ret><nametext>*erl_gethostbyname(name)</nametext></name>
<name><ret>struct hostent</ret><nametext>*erl_gethostbyname_r(name, hostp, buffer, buflen, h_errnop)</nametext></name>
+
<fsummary>Name lookup functions.</fsummary>
<type>
<v>const char *name;</v>
@@ -550,7 +639,7 @@ typedef struct {
<v>int *h_errnop;</v>
</type>
<desc>
- <p>These are convenience functions for some common name lookup functions.</p>
+ <p>Convenience functions for some common name lookup functions.</p>
</desc>
</func>
</funcs>
@@ -558,12 +647,13 @@ typedef struct {
<section>
<title>Debug Information</title>
<p>If a connection attempt fails, the following can be checked:</p>
+
<list type="bulleted">
<item><c><![CDATA[erl_errno]]></c></item>
- <item>that the right cookie was used</item>
- <item>that <em>epmd</em> is running</item>
- <item>the remote Erlang node on the other side is running the same
- version of Erlang as the <c><![CDATA[erl_interface]]></c> library.</item>
+ <item>That the correct cookie was used</item>
+ <item>That EPMD is running</item>
+ <item>That the remote Erlang node on the other side is running the same
+ version of Erlang as the <c><![CDATA[erl_interface]]></c> library</item>
</list>
</section>
</cref>
diff --git a/lib/erl_interface/doc/src/erl_error.xml b/lib/erl_interface/doc/src/erl_error.xml
index 5b8d546e12..a85969d7ff 100644
--- a/lib/erl_interface/doc/src/erl_error.xml
+++ b/lib/erl_interface/doc/src/erl_error.xml
@@ -28,21 +28,23 @@
<docno></docno>
<approved>Bjarne D&auml;cker</approved>
<checked>Torbj&ouml;rn T&ouml;rnkvist</checked>
- <date>961014</date>
+ <date>1996-10-14</date>
<rev>A</rev>
<file>erl_error.xml</file>
</header>
<lib>erl_error</lib>
- <libsummary>Error Print Routines</libsummary>
+ <libsummary>Error print routines.</libsummary>
<description>
<p>This module contains some error printing routines taken
- from <em>Advanced Programming in the UNIX Environment</em>
- by W. Richard Stevens. </p>
+ from "Advanced Programming in the UNIX Environment"
+ by W. Richard Stevens.</p>
+
<p>These functions are all called in the same manner as
- <c><![CDATA[printf()]]></c>, i.e. with a string containing format specifiers
- followed by a list of corresponding arguments. All output from
+ <c><![CDATA[printf()]]></c>, that is, with a string containing format
+ specifiers followed by a list of corresponding arguments. All output from
these functions is to <c><![CDATA[stderr]]></c>.</p>
</description>
+
<funcs>
<func>
<name><ret>void</ret><nametext>erl_err_msg(FormatStr, ... )</nametext></name>
@@ -55,6 +57,7 @@
function is simply a wrapper for <c><![CDATA[fprintf()]]></c>.</p>
</desc>
</func>
+
<func>
<name><ret>void</ret><nametext>erl_err_quit(FormatStr, ... )</nametext></name>
<fsummary>Fatal error, but not system call error.</fsummary>
@@ -63,11 +66,12 @@
</type>
<desc>
<p>Use this function when a fatal error has occurred that
- is not due to a system call. The message provided by the
- caller is printed and the process terminates with an exit
- value of 1. The function does not return.</p>
+ is not because of a system call. The message provided by the
+ caller is printed and the process terminates with exit
+ value <c>1</c>. This function does not return.</p>
</desc>
</func>
+
<func>
<name><ret>void</ret><nametext>erl_err_ret(FormatStr, ... )</nametext></name>
<fsummary>Non-fatal system call error.</fsummary>
@@ -80,6 +84,7 @@
describing the reason for failure.</p>
</desc>
</func>
+
<func>
<name><ret>void</ret><nametext>erl_err_sys(FormatStr, ... )</nametext></name>
<fsummary>Fatal system call error.</fsummary>
@@ -90,7 +95,7 @@
<p>Use this function after a failed system call. The message
provided by the caller is printed followed by a string
describing the reason for failure, and the process
- terminates with an exit value of 1. The function does not
+ terminates with exit value <c>1</c>. This function does not
return.</p>
</desc>
</func>
@@ -98,37 +103,41 @@
<section>
<title>Error Reporting</title>
- <p>Most functions in erl_interface report failures to the caller by
- returning some otherwise meaningless value (typically <c><![CDATA[NULL]]></c>
+ <p>Most functions in <c>Erl_Interface</c> report failures to the caller by
+ returning some otherwise meaningless value (typically
+ <c><![CDATA[NULL]]></c>
or a negative number). As this only tells you that things did not
- go well, you will have to examine the error code in
- <c><![CDATA[erl_errno]]></c> if you want to find out more about the failure.</p>
+ go well, examine the error code in <c><![CDATA[erl_errno]]></c> if you
+ want to find out more about the failure.</p>
</section>
+
<funcs>
<func>
<name><ret>volatile int</ret><nametext>erl_errno</nametext></name>
- <fsummary>The variable <c><![CDATA[erl_errno]]></c>contains the erl_interface error number. You can change the value if you wish.</fsummary>
+ <fsummary>Variable <c><![CDATA[erl_errno]]></c> contains the
+ Erl_Interface error number. You can change the value if you wish.
+ </fsummary>
<desc>
- <p><c><![CDATA[erl_errno]]></c> is initially (at program startup) zero and
- is then set by many erl_interface functions on failure to a
- non-zero error code to indicate what kind of error it
- encountered. A successful function call might change
+ <p><c><![CDATA[erl_errno]]></c> is initially (at program startup) zero
+ and is then set by many <c>Erl_Interface</c> functions on failure to
+ a non-zero error code to indicate what kind of error it
+ encountered. A successful function call can change
<c><![CDATA[erl_errno]]></c> (by calling some other function that
- fails), but no function will ever set it to zero. This means
+ fails), but no function does never set it to zero. This means
that you cannot use <c><![CDATA[erl_errno]]></c> to see <em>if</em> a
function call failed. Instead, each function reports failure
in its own way (usually by returning a negative number or
- <c><![CDATA[NULL]]></c>), in which case you can examine <c><![CDATA[erl_errno]]></c>
- for details.</p>
+ <c><![CDATA[NULL]]></c>), in which case you can examine
+ <c><![CDATA[erl_errno]]></c> for details.</p>
<p><c><![CDATA[erl_errno]]></c> uses the error codes defined in your
system's <c><![CDATA[<errno.h>]]></c>.</p>
<note>
- <p>Actually, <c><![CDATA[erl_errno]]></c> is a "modifiable lvalue" (just
+ <p><c><![CDATA[erl_errno]]></c> is a "modifiable lvalue" (just
like ISO C defines <c><![CDATA[errno]]></c> to be) rather than a
- variable. This means it might be implemented as a macro
- (expanding to, e.g., <c><![CDATA[*_erl_errno()]]></c>). For reasons of
- thread- (or task-)safety, this is exactly what we do on most
- platforms.</p>
+ variable. This means it can be implemented as a macro
+ (expanding to, for example, <c><![CDATA[*_erl_errno()]]></c>).
+ For reasons of thread safety (or task safety), this is exactly what
+ we do on most platforms.</p>
</note>
</desc>
</func>
diff --git a/lib/erl_interface/doc/src/erl_eterm.xml b/lib/erl_interface/doc/src/erl_eterm.xml
index e5207a271e..8a46c20432 100644
--- a/lib/erl_interface/doc/src/erl_eterm.xml
+++ b/lib/erl_interface/doc/src/erl_eterm.xml
@@ -28,23 +28,26 @@
<docno></docno>
<approved>Bjarne D&auml;cker</approved>
<checked>Torbj&ouml;rn T&ouml;rnkvist</checked>
- <date>980703</date>
+ <date>1998-07-03</date>
<rev>A</rev>
<file>erl_eterm.xml</file>
</header>
<lib>erl_eterm</lib>
- <libsummary>Functions for Erlang Term Construction</libsummary>
+ <libsummary>Functions for Erlang term construction.</libsummary>
<description>
- <p>This module contains functions for creating and manipulating
- Erlang terms. </p>
+ <p>This module provides functions for creating and manipulating
+ Erlang terms.</p>
+
<p>An Erlang term is represented by a C structure of type
- <c><![CDATA[ETERM]]></c>. Applications should not reference any fields in this
- structure directly, because it may be changed in future releases
+ <c><![CDATA[ETERM]]></c>. Applications should not reference any fields
+ in this structure directly, as it can be changed in future releases
to provide faster and more compact term storage. Instead,
- applications should us the macros and functions provided. </p>
- <p>The following macros each take a single ETERM pointer as an
- argument. They return a non-zero value if the test is true, and 0
- otherwise:</p>
+ applications should use the macros and functions provided.</p>
+
+ <p>Each of the following macros takes a single <c>ETERM</c> pointer as an
+ argument. The macros return a non-zero value if the test is true,
+ otherwise <c>0</c>.</p>
+
<taglist>
<tag><c><![CDATA[ERL_IS_INTEGER(t)]]></c></tag>
<item>True if <c><![CDATA[t]]></c> is an integer.</item>
@@ -55,7 +58,7 @@
<tag><c><![CDATA[ERL_IS_ATOM(t)]]></c></tag>
<item>True if <c><![CDATA[t]]></c> is an atom.</item>
<tag><c><![CDATA[ERL_IS_PID(t)]]></c></tag>
- <item>True if <c><![CDATA[t]]></c> is a Pid (process identifier).</item>
+ <item>True if <c><![CDATA[t]]></c> is a pid (process identifier).</item>
<tag><c><![CDATA[ERL_IS_PORT(t)]]></c></tag>
<item>True if <c><![CDATA[t]]></c> is a port.</item>
<tag><c><![CDATA[ERL_IS_REF(t)]]></c></tag>
@@ -65,29 +68,31 @@
<tag><c><![CDATA[ERL_IS_BINARY(t)]]></c></tag>
<item>True if <c><![CDATA[t]]></c> is a binary.</item>
<tag><c><![CDATA[ERL_IS_LIST(t)]]></c></tag>
- <item>True if <c><![CDATA[t]]></c> is a list with zero or more elements.</item>
+ <item>True if <c><![CDATA[t]]></c> is a list with zero or more
+ elements.</item>
<tag><c><![CDATA[ERL_IS_EMPTY_LIST(t)]]></c></tag>
<item>True if <c><![CDATA[t]]></c> is an empty list.</item>
<tag><c><![CDATA[ERL_IS_CONS(t)]]></c></tag>
- <item>True if <c><![CDATA[t]]></c> is a list with at least one element.</item>
+ <item>True if <c><![CDATA[t]]></c> is a list with at least one
+ element.</item>
</taglist>
+
<p>The following macros can be used for retrieving parts of Erlang
- terms. None of these do any type checking; results are undefined
- if you pass an ETERM* containing the wrong type. For example,
- passing a tuple to ERL_ATOM_PTR() will likely result in garbage.
- </p>
+ terms. None of these do any type checking. Results are undefined
+ if you pass an <c>ETERM*</c> containing the wrong type. For example,
+ passing a tuple to <c>ERL_ATOM_PTR()</c> likely results in garbage.</p>
+
<taglist>
<tag><c><![CDATA[char *ERL_ATOM_PTR(t)]]></c></tag>
- <item/>
+ <item></item>
<tag><c><![CDATA[char *ERL_ATOM_PTR_UTF8(t)]]></c></tag>
- <item>A string representing atom <c><![CDATA[t]]></c>.
- </item>
+ <item>A string representing atom <c><![CDATA[t]]></c>.</item>
<tag><c><![CDATA[int ERL_ATOM_SIZE(t)]]></c></tag>
- <item/>
+ <item></item>
<tag><c><![CDATA[int ERL_ATOM_SIZE_UTF8(t)]]></c></tag>
- <item>The length (in bytes) of atom t.</item>
+ <item>The length (in bytes) of atom <c><![CDATA[t]]></c>.</item>
<tag><c><![CDATA[void *ERL_BIN_PTR(t)]]></c></tag>
- <item>A pointer to the contents of <c><![CDATA[t]]></c></item>
+ <item>A pointer to the contents of <c><![CDATA[t]]></c>.</item>
<tag><c><![CDATA[int ERL_BIN_SIZE(t)]]></c></tag>
<item>The length (in bytes) of binary object <c><![CDATA[t]]></c>.</item>
<tag><c><![CDATA[int ERL_INT_VALUE(t)]]></c></tag>
@@ -97,9 +102,9 @@
<tag><c><![CDATA[double ERL_FLOAT_VALUE(t)]]></c></tag>
<item>The floating point value of <c><![CDATA[t]]></c>.</item>
<tag><c><![CDATA[ETERM *ERL_PID_NODE(t)]]></c></tag>
- <item/>
+ <item></item>
<tag><c><![CDATA[ETERM *ERL_PID_NODE_UTF8(t)]]></c></tag>
- <item>The Node in pid <c><![CDATA[t]]></c>.</item>
+ <item>The node in pid <c><![CDATA[t]]></c>.</item>
<tag><c><![CDATA[int ERL_PID_NUMBER(t)]]></c></tag>
<item>The sequence number in pid <c><![CDATA[t]]></c>.</item>
<tag><c><![CDATA[int ERL_PID_SERIAL(t)]]></c></tag>
@@ -111,16 +116,18 @@
<tag><c><![CDATA[int ERL_PORT_CREATION(t)]]></c></tag>
<item>The creation number in port <c><![CDATA[t]]></c>.</item>
<tag><c><![CDATA[ETERM *ERL_PORT_NODE(t)]]></c></tag>
- <item/>
+ <item></item>
<tag><c><![CDATA[ETERM *ERL_PORT_NODE_UTF8(t)]]></c></tag>
<item>The node in port <c><![CDATA[t]]></c>.</item>
<tag><c><![CDATA[int ERL_REF_NUMBER(t)]]></c></tag>
- <item>The first part of the reference number in ref <c><![CDATA[t]]></c>. Use
- only for compatibility.</item>
+ <item>The first part of the reference number in ref <c><![CDATA[t]]></c>.
+ Use only for compatibility.</item>
<tag><c><![CDATA[int ERL_REF_NUMBERS(t)]]></c></tag>
- <item>Pointer to the array of reference numbers in ref <c><![CDATA[t]]></c>.</item>
+ <item>Pointer to the array of reference numbers in ref
+ <c><![CDATA[t]]></c>.</item>
<tag><c><![CDATA[int ERL_REF_LEN(t)]]></c></tag>
- <item>The number of used reference numbers in ref <c><![CDATA[t]]></c>.</item>
+ <item>The number of used reference numbers in ref
+ <c><![CDATA[t]]></c>.</item>
<tag><c><![CDATA[int ERL_REF_CREATION(t)]]></c></tag>
<item>The creation number in ref <c><![CDATA[t]]></c>.</item>
<tag><c><![CDATA[int ERL_TUPLE_SIZE(t)]]></c></tag>
@@ -128,31 +135,38 @@
<tag><c><![CDATA[ETERM *ERL_CONS_HEAD(t)]]></c></tag>
<item>The head element of list <c><![CDATA[t]]></c>.</item>
<tag><c><![CDATA[ETERM *ERL_CONS_TAIL(t)]]></c></tag>
- <item>A List representing the tail elements of list <c><![CDATA[t]]></c>.</item>
+ <item>A list representing the tail elements of list
+ <c><![CDATA[t]]></c>.</item>
</taglist>
</description>
+
<funcs>
<func>
<name><ret>ETERM *</ret><nametext>erl_cons(head, tail)</nametext></name>
- <fsummary>Prepends a term to the head of a list.</fsummary>
+ <fsummary>Prepend a term to the head of a list.</fsummary>
<type>
<v>ETERM *head;</v>
<v>ETERM *tail;</v>
</type>
<desc>
- <p>This function concatenates two Erlang terms, prepending
- <c><![CDATA[head]]></c> onto <c><![CDATA[tail]]></c> and thereby creating a <c><![CDATA[cons]]></c> cell.
- To make a proper list, <c><![CDATA[tail]]></c> should always be a
- list or an empty list. Note that NULL is not a valid list.</p>
- <p><c><![CDATA[head]]></c> is the new term to be added.</p>
- <p><c><![CDATA[tail]]></c> is the existing list to which <c><![CDATA[head]]></c> will
- be concatenated.</p>
+ <p>Concatenates two Erlang terms, prepending <c><![CDATA[head]]></c>
+ onto <c><![CDATA[tail]]></c> and thereby creating a
+ <c><![CDATA[cons]]></c> cell.
+ To make a proper list, <c><![CDATA[tail]]></c> is always to be a list
+ or an empty list. Notice that <c>NULL</c> is not a valid list.</p>
+ <list type="bulleted">
+ <item><c><![CDATA[head]]></c> is the new term to be added.</item>
+ <item><c><![CDATA[tail]]></c> is the existing list to which
+ <c><![CDATA[head]]></c> is concatenated.</item>
+ </list>
<p>The function returns a new list.</p>
- <p><c><![CDATA[ERL_CONS_HEAD(list)]]></c> and <c><![CDATA[ERL_CONS_TAIL(list)]]></c>
+ <p><c><![CDATA[ERL_CONS_HEAD(list)]]></c> and
+ <c><![CDATA[ERL_CONS_TAIL(list)]]></c>
can be used to retrieve the head and tail components
- from the list. <c><![CDATA[erl_hd(list)]]></c> and <c><![CDATA[erl_tl(list)]]></c> will do
+ from the list. <c><![CDATA[erl_hd(list)]]></c> and
+ <c><![CDATA[erl_tl(list)]]></c> do
the same thing, but check that the argument really is a list.</p>
- <p>For example:</p>
+ <p><em>Example:</em></p>
<code type="none"><![CDATA[
ETERM *list,*anAtom,*anInt;
anAtom = erl_mk_atom("madonna");
@@ -165,50 +179,56 @@ erl_free_compound(list);
]]></code>
</desc>
</func>
+
<func>
<name><ret>ETERM *</ret><nametext>erl_copy_term(term)</nametext></name>
- <fsummary>Creates a copy of an Erlang term.</fsummary>
+ <fsummary>Create a copy of an Erlang term.</fsummary>
<type>
<v>ETERM *term;</v>
</type>
<desc>
- <p>This function creates and returns a copy of the Erlang term
+ <p>Creates and returns a copy of the Erlang term
<c><![CDATA[term]]></c>.</p>
</desc>
</func>
+
<func>
<name><ret>ETERM *</ret><nametext>erl_element(position, tuple)</nametext></name>
- <fsummary>Extracts an element from an Erlang tuple.</fsummary>
+ <fsummary>Extract an element from an Erlang tuple.</fsummary>
<type>
<v>int position;</v>
<v>ETERM *tuple;</v>
</type>
<desc>
- <p>This function extracts a specified element from an Erlang
- tuple. </p>
- <p><c><![CDATA[position]]></c> specifies which element to retrieve from
- <c><![CDATA[tuple]]></c>. The elements are numbered starting from 1.</p>
- <p><c><![CDATA[tuple]]></c> is an Erlang term containing at least
- <c><![CDATA[position]]></c> elements.</p>
- <p>The function returns a new Erlang term corresponding to the
- requested element, or NULL if <c><![CDATA[position]]></c> was greater than
- the arity of <c><![CDATA[tuple]]></c>.</p>
+ <p>Extracts a specified element from an Erlang tuple.</p>
+ <iist type="bulleted">
+ <item><c><![CDATA[position]]></c> specifies which element to retrieve
+ from <c><![CDATA[tuple]]></c>. The elements are numbered starting
+ from 1.</item>
+ <item><c><![CDATA[tuple]]></c> is an Erlang term containing at least
+ <c><![CDATA[position]]></c> elements.</item>
+ </iist>
+ <p>Returns a new Erlang term corresponding to the requested element, or
+ <c>NULL</c> if <c><![CDATA[position]]></c> was greater
+ than the arity of <c><![CDATA[tuple]]></c>.</p>
</desc>
</func>
+
<func>
<name><ret>ETERM *</ret><nametext>erl_hd(list)</nametext></name>
- <fsummary>Extracts the first element from a list.</fsummary>
+ <fsummary>Extract the first element from a list.</fsummary>
<type>
<v>ETERM *list;</v>
</type>
<desc>
<p>Extracts the first element from a list.</p>
<p><c><![CDATA[list]]></c> is an Erlang term containing a list.</p>
- <p>The function returns an Erlang term corresponding to the
- head element in the list, or a NULL pointer if <c><![CDATA[list]]></c> was
- not a list.</p>
+ <p>Returns an Erlang term corresponding to the head
+ head element in the list, or a <c>NULL</c> pointer if
+ <c><![CDATA[list]]></c> was not a list.</p>
</desc>
</func>
+
<func>
<name><ret>void</ret><nametext>erl_init(NULL, 0)</nametext></name>
<fsummary>Initialization routine.</fsummary>
@@ -218,42 +238,45 @@ erl_free_compound(list);
</type>
<desc>
<marker id="erl_init"></marker>
- <p>This function must be called before any of the others in
- the <c><![CDATA[erl_interface]]></c> library in order to initialize the
+ <p>This function must be called before any of the others in the
+ <c><![CDATA[Erl_Interface]]></c> library to initialize the
library functions. The arguments must be specified as
<c><![CDATA[erl_init(NULL,0)]]></c>.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>erl_iolist_length(list)</nametext></name>
- <fsummary>Return the length of an IO list.</fsummary>
+ <fsummary>Return the length of an I/O list.</fsummary>
<type>
<v>ETERM *list;</v>
</type>
<desc>
- <p>Returns the length of an IO list.
- </p>
- <p><c><![CDATA[list]]></c> is an Erlang term containing an IO list. </p>
- <p>The function returns the length of <c><![CDATA[list]]></c>, or -1 if
- <c><![CDATA[list]]></c> is not an IO list.</p>
- <p>Refer to <c><![CDATA[erl_iolist_to_binary()]]></c> for the definition of
- an IO list. </p>
+ <p>Returns the length of an I/O list.</p>
+ <p><c><![CDATA[list]]></c> is an Erlang term containing an I/O list.</p>
+ <p>Returns the length of <c><![CDATA[list]]></c>, or
+ <c>-1</c> if <c><![CDATA[list]]></c> is not an I/O list.</p>
+ <p>For the definition of an I/O list, see
+ <seealso marker="#erl_iolist_to_binary">
+ <c>erl_iolist_to_binary</c></seealso>.</p>
</desc>
</func>
+
<func>
<name><ret>ETERM *</ret><nametext>erl_iolist_to_binary(term)</nametext></name>
- <fsummary>Converts an IO list to a binary.</fsummary>
+ <fsummary>Convert an I/O list to a binary.</fsummary>
<type>
<v>ETERM *list;</v>
</type>
<desc>
- <p>This function converts an IO list to a binary term.</p>
+ <p>Converts an I/O list to a binary term.</p>
<p><c><![CDATA[list]]></c> is an Erlang term containing a list.</p>
- <p>This function an Erlang binary term, or NULL if <c><![CDATA[list]]></c>
- was not an IO list. </p>
- <p>Informally, an IO list is a deep list of characters and
- binaries which can be sent to an Erlang port. In BNF, an IO
- list is formally defined as follows: </p>
+ <p>Returns an Erlang binary term, or <c>NULL</c> if
+ <c><![CDATA[list]]></c> was not an I/O list.</p>
+ <marker id="erl_iolist_to_binary"></marker>
+ <p>Informally, an I/O list is a deep list of characters and
+ binaries that can be sent to an Erlang port. In BNF, an I/O
+ list is formally defined as follows:</p>
<code type="none"><![CDATA[
iolist ::= []
| Binary
@@ -266,44 +289,49 @@ iohead ::= Binary
]]></code>
</desc>
</func>
+
<func>
<name><ret>char *</ret><nametext>erl_iolist_to_string(list)</nametext></name>
- <fsummary>Converts an IO list to a zero terminated string.</fsummary>
+ <fsummary>Convert an I/O list to a zero-terminated string.</fsummary>
<type>
<v>ETERM *list;</v>
</type>
<desc>
- <p>This function converts an IO list to a '\0' terminated C
- string. </p>
- <p><c><![CDATA[list]]></c> is an Erlang term containing an IO list. The IO
- list must not contain the integer 0, since C strings may not
+ <p>Converts an I/O list to a '\0' terminated C string.</p>
+ <p><c><![CDATA[list]]></c> is an Erlang term containing an I/O list.
+ The I/O list must not contain the integer 0, as C strings may not
contain this value except as a terminating marker.</p>
- <p>This function returns a pointer to a dynamically allocated
- buffer containing a string. If <c><![CDATA[list]]></c> is not an IO list,
- or if <c><![CDATA[list]]></c> contains the integer 0, NULL is returned. It
- is the caller's responsibility free the allocated buffer
- with <c><![CDATA[erl_free()]]></c>. </p>
- <p>Refer to <c><![CDATA[erl_iolist_to_binary()]]></c> for the definition of an
- IO list. </p>
+ <p>Returns a pointer to a dynamically allocated
+ buffer containing a string. If <c><![CDATA[list]]></c> is not an I/O
+ list, or if <c><![CDATA[list]]></c> contains the integer 0,
+ <c>NULL</c> is returned. It
+ is the caller's responsibility to free the allocated buffer
+ with <c><![CDATA[erl_free()]]></c>.</p>
+ <p>For the definition of an I/O list, see
+ <seealso marker="#erl_iolist_to_binary">
+ <c>erl_iolist_to_binary</c></seealso>.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>erl_length(list)</nametext></name>
- <fsummary>Determines the length of a list.</fsummary>
+ <fsummary>Determine the length of a list.</fsummary>
<type>
<v>ETERM *list;</v>
</type>
<desc>
<p>Determines the length of a proper list.</p>
- <p><c><![CDATA[list]]></c> is an Erlang term containing proper list. In a
- proper list, all tails except the last point to another list
+ <p><c><![CDATA[list]]></c> is an Erlang term containing a proper list.
+ In a proper list, all tails except the last point to another list
cell, and the last tail points to an empty list.</p>
- <p>Returns -1 if <c><![CDATA[list]]></c> is not a proper list.</p>
+ <p>Returns <c>-1</c> if <c><![CDATA[list]]></c> is not a proper
+ list.</p>
</desc>
</func>
+
<func>
<name><ret>ETERM *</ret><nametext>erl_mk_atom(string)</nametext></name>
- <fsummary>Creates an atom.</fsummary>
+ <fsummary>Create an atom.</fsummary>
<type>
<v>const char *string;</v>
</type>
@@ -311,97 +339,114 @@ iohead ::= Binary
<p>Creates an atom.</p>
<p><c><![CDATA[string]]></c> is the sequence of characters that will be
used to create the atom.</p>
- <p>Returns an Erlang term containing an atom. Note that it is
- the callers responsibility to make sure that <c><![CDATA[string]]></c>
+ <p>Returns an Erlang term containing an atom. Notice that it is
+ the caller's responsibility to ensure that <c><![CDATA[string]]></c>
contains a valid name for an atom.</p>
- <p><c><![CDATA[ERL_ATOM_PTR(atom)]]></c> and <c><![CDATA[ERL_ATOM_PTR_UTF8(atom)]]></c>
- can be used to retrieve the atom name (as a null terminated string). <c><![CDATA[ERL_ATOM_SIZE(atom)]]></c>
- and <c><![CDATA[ERL_ATOM_SIZE_UTF8(atom)]]></c> returns the length of the atom name.</p>
- <note><p>Note that the UTF8 variants were introduced in Erlang/OTP releases R16
- and the string returned by <c>ERL_ATOM_PTR(atom)</c> was not null terminated on older releases.</p>
+ <p><c><![CDATA[ERL_ATOM_PTR(atom)]]></c> and
+ <c><![CDATA[ERL_ATOM_PTR_UTF8(atom)]]></c>
+ can be used to retrieve the atom name (as a null-terminated string).
+ <c><![CDATA[ERL_ATOM_SIZE(atom)]]></c>
+ and <c><![CDATA[ERL_ATOM_SIZE_UTF8(atom)]]></c> return the length
+ of the atom name.</p>
+ <note>
+ <p>The UTF-8 variants were introduced in Erlang/OTP R16 and the
+ string returned by <c>ERL_ATOM_PTR(atom)</c> was not
+ null-terminated on older releases.</p>
</note>
</desc>
</func>
+
<func>
<name><ret>ETERM *</ret><nametext>erl_mk_binary(bptr, size)</nametext></name>
- <fsummary>Creates a binary object.</fsummary>
+ <fsummary>Create a binary object.</fsummary>
<type>
<v>char *bptr;</v>
<v>int size;</v>
</type>
<desc>
- <p>This function produces an Erlang binary object from a
+ <p>Produces an Erlang binary object from a
buffer containing a sequence of bytes.</p>
- <p><c><![CDATA[bptr]]></c> is a pointer to a buffer containing data to be converted.</p>
- <p><c><![CDATA[size]]></c> indicates the length of <c><![CDATA[bptr]]></c>.</p>
- <p>The function returns an Erlang binary object.</p>
+ <list type="bulleted">
+ <item><c><![CDATA[bptr]]></c> is a pointer to a buffer containing
+ data to be converted.</item>
+ <item><c><![CDATA[size]]></c> indicates the length of
+ <c><![CDATA[bptr]]></c>.</item>
+ </list>
+ <p>Returns an Erlang binary object.</p>
<p><c><![CDATA[ERL_BIN_PTR(bin)]]></c> retrieves a pointer to
the binary data. <c><![CDATA[ERL_BIN_SIZE(bin)]]></c> retrieves the
- size. </p>
+ size.</p>
</desc>
</func>
+
<func>
<name><ret>ETERM *</ret><nametext>erl_mk_empty_list()</nametext></name>
- <fsummary>Creates an empty Erlang list.</fsummary>
+ <fsummary>Create an empty Erlang list.</fsummary>
<desc>
- <p>This function creates and returns an empty Erlang list.
- Note that NULL is not used to represent an empty list;
+ <p>Creates and returns an empty Erlang list.
+ Notice that <c>NULL</c> is not used to represent an empty list;
Use this function instead.</p>
</desc>
</func>
+
<func>
<name><ret>ETERM *</ret><nametext>erl_mk_estring(string, len)</nametext></name>
- <fsummary>Creates an Erlang string.</fsummary>
+ <fsummary>Create an Erlang string.</fsummary>
<type>
<v>char *string;</v>
<v>int len;</v>
</type>
<desc>
- <p>This function creates a list from a sequence of bytes.</p>
- <p><c><![CDATA[string]]></c> is a buffer containing a sequence of
- bytes. The buffer does not need to be zero-terminated.</p>
- <p><c><![CDATA[len]]></c> is the length of <c><![CDATA[string]]></c>.</p>
- <p>The function returns an Erlang list object corresponding to
+ <p>Creates a list from a sequence of bytes.</p>
+ <list type="bulleted">
+ <item><c><![CDATA[string]]></c> is a buffer containing a sequence of
+ bytes. The buffer does not need to be zero-terminated.</item>
+ <item><c><![CDATA[len]]></c> is the length of
+ <c><![CDATA[string]]></c>.</item>
+ </list>
+ <p>Returns an Erlang list object corresponding to
the character sequence in <c><![CDATA[string]]></c>.</p>
</desc>
</func>
+
<func>
<name><ret>ETERM *</ret><nametext>erl_mk_float(f)</nametext></name>
- <fsummary>Creates an Erlang float.</fsummary>
+ <fsummary>Create an Erlang float.</fsummary>
<type>
<v>double f;</v>
</type>
<desc>
<p>Creates an Erlang float.</p>
- <p><c><![CDATA[f]]></c> is a value to be converted to an Erlang float.</p>
- <p></p>
- <p>The function returns an Erlang float object with the value
- specified in <c><![CDATA[f]]></c> or <c><![CDATA[NULL]]></c> if
- <c><![CDATA[f]]></c> is not finite.
- </p>
+ <p><c><![CDATA[f]]></c> is a value to be converted to an Erlang
+ float.</p>
+ <p>Returns an Erlang float object with the value
+ specified in <c><![CDATA[f]]></c> or <c><![CDATA[NULL]]></c> if
+ <c><![CDATA[f]]></c> is not finite.</p>
<p><c><![CDATA[ERL_FLOAT_VALUE(t)]]></c> can be used to retrieve the
- value from an Erlang float.</p>
+ value from an Erlang float.</p>
</desc>
</func>
+
<func>
<name><ret>ETERM *</ret><nametext>erl_mk_int(n)</nametext></name>
- <fsummary>Creates an Erlang integer.</fsummary>
+ <fsummary>Create an Erlang integer.</fsummary>
<type>
<v>int n;</v>
</type>
<desc>
<p>Creates an Erlang integer.</p>
- <p><c><![CDATA[n]]></c> is a value to be converted to an Erlang integer.</p>
- <p></p>
- <p>The function returns an Erlang integer object with the
+ <p><c><![CDATA[n]]></c> is a value to be converted to an Erlang
+ integer.</p>
+ <p>Returns an Erlang integer object with the
value specified in <c><![CDATA[n]]></c>.</p>
- <p><c><![CDATA[ERL_INT_VALUE(t)]]></c> can be used to retrieve the value
+ <p><c><![CDATA[ERL_INT_VALUE(t)]]></c> can be used to retrieve the
value from an Erlang integer.</p>
</desc>
</func>
+
<func>
<name><ret>ETERM *</ret><nametext>erl_mk_list(array, arrsize)</nametext></name>
- <fsummary>Creates a list from an array.</fsummary>
+ <fsummary>Create a list from an array.</fsummary>
<type>
<v>ETERM **array;</v>
<v>int arrsize;</v>
@@ -409,44 +454,51 @@ iohead ::= Binary
<desc>
<p>Creates an Erlang list from an array of Erlang terms, such
that each element in the list corresponds to one element in
- the array. </p>
- <p><c><![CDATA[array]]></c> is an array of Erlang terms.</p>
- <p><c><![CDATA[arrsize]]></c> is the number of elements in <c><![CDATA[array]]></c>.</p>
+ the array.</p>
+ <list type="bulleted">
+ <item><c><![CDATA[array]]></c> is an array of Erlang terms.</item>
+ <item><c><![CDATA[arrsize]]></c> is the number of elements in
+ <c><![CDATA[array]]></c>.</item>
+ </list>
<p>The function creates an Erlang list object, whose length
- <c><![CDATA[arrsize]]></c> and whose elements are taken from the terms in
- <c><![CDATA[array]]></c>.</p>
+ <c><![CDATA[arrsize]]></c> and whose elements are taken from the
+ terms in <c><![CDATA[array]]></c>.</p>
</desc>
</func>
+
<func>
<name><ret>ETERM *</ret><nametext>erl_mk_long_ref(node, n1, n2, n3, creation)</nametext></name>
- <fsummary>Creates an Erlang reference.</fsummary>
+ <fsummary>Create an Erlang reference.</fsummary>
<type>
<v>const char *node;</v>
<v>unsigned int n1, n2, n3;</v>
<v>unsigned int creation;</v>
</type>
<desc>
- <p>This function creates an Erlang reference, with 82 bits.</p>
- <p><c><![CDATA[node]]></c> is the name of the C node.</p>
- <p><c><![CDATA[n1]]></c>, <c><![CDATA[n2]]></c> and <c><![CDATA[n3]]></c> can be seen as one big number
- <c><![CDATA[n1*2^64+n2*2^32+n3]]></c> which should be chosen uniquely for
- each reference
- created for a given C node.</p>
- <p><c><![CDATA[creation]]></c> is an arbitrary number.</p>
- <p>Note that <c><![CDATA[n3]]></c> and <c><![CDATA[creation]]></c> are limited in
- precision, so only the low 18 and 2 bits of these numbers
- are actually used.
- </p>
- <p>The function returns an Erlang reference object.</p>
- <p><c><![CDATA[ERL_REF_NODE(ref)]]></c>, <c><![CDATA[ERL_REF_NUMBERS(ref)]]></c>,
- <c><![CDATA[ERL_REF_LEN(ref)]]></c> and
- <c><![CDATA[ERL_REF_CREATION(ref)]]></c> to retrieve the values used
- to create the reference. </p>
+ <p>Creates an Erlang reference, with 82 bits.</p>
+ <list type="bulleted">
+ <item><c><![CDATA[node]]></c> is the name of the C-node.</item>
+ <item><c><![CDATA[n1]]></c>, <c><![CDATA[n2]]></c>, and
+ <c><![CDATA[n3]]></c> can be seen as one big number
+ <c><![CDATA[n1*2^64+n2*2^32+n3]]></c>, which is to be chosen
+ uniquely for each reference created for a given C-node.</item>
+ <item><c><![CDATA[creation]]></c> is an arbitrary number.</item>
+ </list>
+ <p>Notice that <c><![CDATA[n3]]></c> and <c><![CDATA[creation]]></c>
+ are limited in precision, so only the low 18 and 2 bits of these
+ numbers are used.</p>
+ <p>Returns an Erlang reference object.</p>
+ <p><c><![CDATA[ERL_REF_NODE(ref)]]></c>,
+ <c><![CDATA[ERL_REF_NUMBERS(ref)]]></c>,
+ <c><![CDATA[ERL_REF_LEN(ref)]]></c>, and
+ <c><![CDATA[ERL_REF_CREATION(ref)]]></c> can be used to retrieve the
+ values used to create the reference.</p>
</desc>
</func>
+
<func>
<name><ret>ETERM *</ret><nametext>erl_mk_pid(node, number, serial, creation)</nametext></name>
- <fsummary>Creates a process identifier.</fsummary>
+ <fsummary>Create a process identifier.</fsummary>
<type>
<v>const char *node;</v>
<v>unsigned int number;</v>
@@ -454,106 +506,125 @@ iohead ::= Binary
<v>unsigned int creation;</v>
</type>
<desc>
- <p>This function creates an Erlang process identifier. The
+ <p>Creates an Erlang process identifier (pid). The
resulting pid can be used by Erlang processes wishing to
- communicate with the C node.</p>
- <p><c><![CDATA[node]]></c> is the name of the C node.</p>
- <p><c><![CDATA[number]]></c>, <c><![CDATA[serial]]></c> and <c><![CDATA[creation]]></c> are
- arbitrary numbers. Note though, that these are limited in
- precision, so only the low 15, 3 and 2 bits of these numbers
- are actually used.</p>
- <p>The function returns an Erlang pid object.</p>
- <p><c><![CDATA[ERL_PID_NODE(pid)]]></c>, <c><![CDATA[ERL_PID_NUMBER(pid)]]></c>,
- <c><![CDATA[ERL_PID_SERIAL(pid)]]></c> and <c><![CDATA[ERL_PID_CREATION(pid)]]></c>
+ communicate with the C-node.</p>
+ <list type="bulleted">
+ <item><c><![CDATA[node]]></c> is the name of the C-node.</item>
+ <item><c><![CDATA[number]]></c>, <c><![CDATA[serial]]></c>, and
+ <c><![CDATA[creation]]></c> are
+ arbitrary numbers. Notice that these are limited in
+ precision, so only the low 15, 3, and 2 bits of these numbers
+ are used.</item>
+ </list>
+ <p>Returns an Erlang pid object.</p>
+ <p><c><![CDATA[ERL_PID_NODE(pid)]]></c>,
+ <c><![CDATA[ERL_PID_NUMBER(pid)]]></c>,
+ <c><![CDATA[ERL_PID_SERIAL(pid)]]></c>, and
+ <c><![CDATA[ERL_PID_CREATION(pid)]]></c>
can be used to retrieve the four values used to create the pid.</p>
</desc>
</func>
+
<func>
<name><ret>ETERM *</ret><nametext>erl_mk_port(node, number, creation)</nametext></name>
- <fsummary>Creates a port identifier.</fsummary>
+ <fsummary>Create a port identifier.</fsummary>
<type>
<v>const char *node;</v>
<v>unsigned int number;</v>
<v>unsigned int creation;</v>
</type>
<desc>
- <p>This function creates an Erlang port identifier. </p>
- <p><c><![CDATA[node]]></c> is the name of the C node.</p>
- <p><c><![CDATA[number]]></c> and <c><![CDATA[creation]]></c> are arbitrary numbers.
- Note though, that these are limited in
- precision, so only the low 18 and 2 bits of these numbers
- are actually used.</p>
- <p>The function returns an Erlang port object.</p>
- <p><c><![CDATA[ERL_PORT_NODE(port)]]></c>, <c><![CDATA[ERL_PORT_NUMBER(port)]]></c>
- and <c><![CDATA[ERL_PORT_CREATION]]></c> can be used to retrieve the three
- values used to create the port. </p>
+ <p>Creates an Erlang port identifier.</p>
+ <list type="bulleted">
+ <item><c><![CDATA[node]]></c> is the name of the C-node.</item>
+ <item><c><![CDATA[number]]></c> and <c><![CDATA[creation]]></c> are
+ arbitrary numbers. Notice that these are limited in
+ precision, so only the low 18 and 2 bits of these numbers
+ are used.</item>
+ </list>
+ <p>Returns an Erlang port object.</p>
+ <p><c><![CDATA[ERL_PORT_NODE(port)]]></c>,
+ <c><![CDATA[ERL_PORT_NUMBER(port)]]></c>,
+ and <c><![CDATA[ERL_PORT_CREATION]]></c> can be used to retrieve the
+ three values used to create the port.</p>
</desc>
</func>
+
<func>
<name><ret>ETERM *</ret><nametext>erl_mk_ref(node, number, creation)</nametext></name>
- <fsummary>Creates an old Erlang reference.</fsummary>
+ <fsummary>Create an old Erlang reference.</fsummary>
<type>
<v>const char *node;</v>
<v>unsigned int number;</v>
<v>unsigned int creation;</v>
</type>
<desc>
- <p>This function creates an old Erlang reference, with
+ <p>Creates an old Erlang reference, with
only 18 bits - use <c><![CDATA[erl_mk_long_ref]]></c> instead.</p>
- <p><c><![CDATA[node]]></c> is the name of the C node.</p>
- <p><c><![CDATA[number]]></c> should be chosen uniquely for each reference
- created for a given C node.</p>
- <p><c><![CDATA[creation]]></c> is an arbitrary number.</p>
- <p>Note that <c><![CDATA[number]]></c> and <c><![CDATA[creation]]></c> are limited in
- precision, so only the low 18 and 2 bits of these numbers
- are actually used.
- </p>
- <p>The function returns an Erlang reference object.</p>
- <p><c><![CDATA[ERL_REF_NODE(ref)]]></c>, <c><![CDATA[ERL_REF_NUMBER(ref)]]></c>, and
- <c><![CDATA[ERL_REF_CREATION(ref)]]></c> to retrieve the three values used
- to create the reference. </p>
+ <list type="bulleted">
+ <item><c><![CDATA[node]]></c> is the name of the C-node.</item>
+ <item><c><![CDATA[number]]></c> is to be chosen uniquely for each
+ reference created for a given C-node.</item>
+ <item><c><![CDATA[creation]]></c> is an arbitrary number.</item>
+ </list>
+ <p>Notice that <c><![CDATA[number]]></c> and <c><![CDATA[creation]]></c>
+ are limited in precision, so only the low 18 and 2 bits of these
+ numbers are used.</p>
+ <p>Returns an Erlang reference object.</p>
+ <p><c><![CDATA[ERL_REF_NODE(ref)]]></c>,
+ <c><![CDATA[ERL_REF_NUMBER(ref)]]></c>, and
+ <c><![CDATA[ERL_REF_CREATION(ref)]]></c> can be used to retrieve the
+ three values used to create the reference.</p>
</desc>
</func>
+
<func>
<name><ret>ETERM *</ret><nametext>erl_mk_string(string)</nametext></name>
- <fsummary>Creates a string.</fsummary>
+ <fsummary>Create a string.</fsummary>
<type>
<v>char *string;</v>
</type>
<desc>
- <p>This function creates a list from a zero terminated string.</p>
- <p><c><![CDATA[string]]></c> is the zero-terminated sequence of characters
- (i.e. a C string) from which the list will be created.</p>
- <p>The function returns an Erlang list.</p>
+ <p>Creates a list from a zero-terminated string.</p>
+ <p><c><![CDATA[string]]></c> is the zero-terminated sequence of
+ characters
+ (that is, a C string) from which the list will be created.</p>
+ <p>Returns an Erlang list.</p>
</desc>
</func>
+
<func>
<name><ret>ETERM *</ret><nametext>erl_mk_tuple(array, arrsize)</nametext></name>
- <fsummary>Creates an Erlang tuple from an array.</fsummary>
+ <fsummary>Create an Erlang tuple from an array.</fsummary>
<type>
<v>ETERM **array;</v>
<v>int arrsize;</v>
</type>
<desc>
<p>Creates an Erlang tuple from an array of Erlang terms.</p>
- <p><c><![CDATA[array]]></c> is an array of Erlang terms.</p>
- <p><c><![CDATA[arrsize]]></c> is the number of elements in <c><![CDATA[array]]></c>.</p>
+ <list type="bulleted">
+ <item><c><![CDATA[array]]></c> is an array of Erlang terms.</item>
+ <item><c><![CDATA[arrsize]]></c> is the number of elements in
+ <c><![CDATA[array]]></c>.</item>
+ </list>
<p>The function creates an Erlang tuple, whose arity is
- <c><![CDATA[size]]></c> and whose elements are taken from the terms in
- <c><![CDATA[array]]></c>.</p>
- <p>To retrieve the size of a tuple, either use the
- <c><![CDATA[erl_size]]></c> function (which checks the type of the checked
- term and works for a binary as well as for a tuple), or the
+ <c><![CDATA[size]]></c> and whose elements are taken from the terms
+ in <c><![CDATA[array]]></c>.</p>
+ <p>To retrieve the size of a tuple, either use function
+ <c><![CDATA[erl_size]]></c> (which checks the type of the
+ checked term and works for a binary as well as for a tuple) or
<c><![CDATA[ERL_TUPLE_SIZE(tuple)]]></c> returns the arity of a tuple.
- <c><![CDATA[erl_size()]]></c> will do the same thing, but it checks that
- the argument really is a tuple.
+ <c><![CDATA[erl_size()]]></c> does the same thing, but it checks
+ that the argument is a tuple.
<c><![CDATA[erl_element(index,tuple)]]></c> returns the element
- corresponding to a given position in the tuple. </p>
+ corresponding to a given position in the tuple.</p>
</desc>
</func>
+
<func>
<name><ret>ETERM *</ret><nametext>erl_mk_uint(n)</nametext></name>
- <fsummary>Creates an unsigned integer.</fsummary>
+ <fsummary>Create an unsigned integer.</fsummary>
<type>
<v>unsigned int n;</v>
</type>
@@ -561,76 +632,83 @@ iohead ::= Binary
<p>Creates an Erlang unsigned integer.</p>
<p><c><![CDATA[n]]></c> is a value to be converted to an Erlang
unsigned integer.</p>
- <p></p>
- <p>The function returns an Erlang unsigned integer object with
+ <p>Returns an Erlang unsigned integer object with
the value specified in <c><![CDATA[n]]></c>.</p>
<p><c><![CDATA[ERL_INT_UVALUE(t)]]></c> can be used to retrieve the
value from an Erlang unsigned integer.</p>
</desc>
</func>
+
<func>
<name><ret>ETERM *</ret><nametext>erl_mk_var(name)</nametext></name>
- <fsummary>Creates an Erlang variable.</fsummary>
+ <fsummary>Create an Erlang variable.</fsummary>
<type>
<v>char *name;</v>
</type>
<desc>
- <p>This function creates an unbound Erlang variable. The
- variable can later be bound through pattern matching or assignment.</p>
+ <p>Creates an unbound Erlang variable. The variable can later be bound
+ through pattern matching or assignment.</p>
<p><c><![CDATA[name]]></c> specifies a name for the variable.</p>
- <p>The function returns an Erlang variable object with the
- name <c><![CDATA[name]]></c>. </p>
+ <p>Returns an Erlang variable object with the
+ name <c><![CDATA[name]]></c>.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>erl_print_term(stream, term)</nametext></name>
- <fsummary>Prints an Erlang term.</fsummary>
+ <fsummary>Print an Erlang term.</fsummary>
<type>
<v>FILE *stream;</v>
<v>ETERM *term;</v>
</type>
<desc>
- <p>This function prints the specified Erlang term to the given
- output stream.</p>
- <p><c><![CDATA[stream]]></c> indicates where the function should send its
- output.</p>
- <p><c><![CDATA[term]]></c> is the Erlang term to print.</p>
- <p>The function returns the number of characters written, or a
- negative value if there was an error.</p>
+ <p>Prints the specified Erlang term to the specified output stream.</p>
+ <list type="bulleted">
+ <item><c><![CDATA[stream]]></c> indicates where the function is to
+ send its output.</item>
+ <item><c><![CDATA[term]]></c> is the Erlang term to print.</item>
+ </list>
+ <p>Returns the number of characters written on success, otherwise a
+ negative value.</p>
</desc>
</func>
+
<func>
<name><ret>void</ret><nametext>erl_set_compat_rel(release_number)</nametext></name>
- <fsummary>Set the erl_interface library in compatibility mode.</fsummary>
+ <fsummary>Set the Erl_Interface library in compatibility mode.</fsummary>
+ <marker id="erl_set_compat_rel"/>
<type>
<v>unsigned release_number;</v>
</type>
<desc>
<marker id="erl_set_compat_rel"></marker>
- <p>By default, the <c><![CDATA[erl_interface]]></c> library is only guaranteed
- to be compatible with other Erlang/OTP components from the same
- release as the <c><![CDATA[erl_interface]]></c> library itself. For example,
- <c><![CDATA[erl_interface]]></c> from the OTP R10 release is not compatible
- with an Erlang emulator from the OTP R9 release by default.</p>
- <p>A call to <c><![CDATA[erl_set_compat_rel(release_number)]]></c> sets the
- <c><![CDATA[erl_interface]]></c> library in compatibility mode of release
- <c><![CDATA[release_number]]></c>. Valid range of <c><![CDATA[release_number]]></c>
+ <p>By default, the <c><![CDATA[Erl_Interface]]></c> library is only
+ guaranteed to be compatible with other Erlang/OTP components from the
+ same release as the <c><![CDATA[Erl_Interface]]></c> library itself.
+ For example, <c><![CDATA[Erl_Interface]]></c> from Erlang/OTP R10
+ is not compatible
+ with an Erlang emulator from Erlang/OTP R9 by default.</p>
+ <p>A call to <c><![CDATA[erl_set_compat_rel(release_number)]]></c> sets
+ the <c><![CDATA[Erl_Interface]]></c> library in compatibility mode of
+ release <c><![CDATA[release_number]]></c>. Valid range of
+ <c><![CDATA[release_number]]></c>
is [7, current release]. This makes it possible to
communicate with Erlang/OTP components from earlier releases.</p>
<note>
<p>If this function is called, it may only be called once
- directly after the call to the
- <seealso marker="#erl_init">erl_init()</seealso> function.</p>
+ directly after the call to function
+ <seealso marker="#erl_init">erl_init()</seealso>.</p>
</note>
<warning>
<p>You may run into trouble if this feature is used
- carelessly. Always make sure that all communicating
+ carelessly. Always ensure that all communicating
components are either from the same Erlang/OTP release, or
from release X and release Y where all components
from release Y are in compatibility mode of release X.</p>
</warning>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>erl_size(term)</nametext></name>
<fsummary>Return the arity of a tuple or binary.</fsummary>
@@ -638,49 +716,55 @@ iohead ::= Binary
<v>ETERM *term;</v>
</type>
<desc>
- <p>Returns the arity of an Erlang tuple, or the
- number of bytes in an Erlang binary object. </p>
- <p><c><![CDATA[term]]></c> is an Erlang tuple or an Erlang binary object.</p>
- <p>The function returns the size of <c><![CDATA[term]]></c> as described
- above, or -1 if <c><![CDATA[term]]></c> is not one of the two supported
- types. </p>
+ <p>Returns either the arity of an Erlang tuple or the
+ number of bytes in an Erlang binary object.</p>
+ <p><c><![CDATA[term]]></c> is an Erlang tuple or an Erlang binary
+ object.</p>
+ <p>Returns the size of <c><![CDATA[term]]></c> as described
+ above, or <c>-1</c> if <c><![CDATA[term]]></c> is not one of the two
+ supported types.</p>
</desc>
</func>
+
<func>
<name><ret>ETERM *</ret><nametext>erl_tl(list)</nametext></name>
- <fsummary>Extracts the tail from a list.</fsummary>
+ <fsummary>Extract the tail from a list.</fsummary>
<type>
<v>ETERM *list;</v>
</type>
<desc>
<p>Extracts the tail from a list.</p>
<p><c><![CDATA[list]]></c> is an Erlang term containing a list.</p>
- <p>The function returns an Erlang list corresponding to the
- original list minus the first element, or NULL pointer if
+ <p>Returns an Erlang list corresponding to the
+ original list minus the first element, or <c>NULL</c> pointer if
<c><![CDATA[list]]></c> was not a list.</p>
</desc>
</func>
+
<func>
<name><ret>ETERM *</ret><nametext>erl_var_content(term, name)</nametext></name>
- <fsummary>Extracts the content of a variable.</fsummary>
+ <fsummary>Extract the content of a variable.</fsummary>
<type>
<v>ETERM *term;</v>
<v>char *name;</v>
</type>
<desc>
- <p>This function returns the contents of the specified
- variable in an Erlang term.
- </p>
- <p><c><![CDATA[term]]></c> is an Erlang term. In order for this function
- to succeed, <c><![CDATA[term]]></c> must be an Erlang variable with the
- specified name, or it must be an Erlang list or tuple
- containing a variable with the specified name. Other Erlang
- types cannot contain variables.</p>
- <p><c><![CDATA[name]]></c> is the name of an Erlang variable.</p>
+ <p>Returns the contents of the specified variable in an Erlang term.</p>
+ <list type="bulleted">
+ <item><c><![CDATA[term]]></c> is an Erlang term. In order for this
+ function to succeed,
+ <c><![CDATA[term]]></c> must either be an Erlang variable with
+ the specified name, or it must be an Erlang list or tuple
+ containing a variable with the specified name. Other Erlang
+ types cannot contain variables.</item>
+ <item><c><![CDATA[name]]></c> is the name of an Erlang variable.
+ </item>
+ </list>
<p>Returns the Erlang object corresponding to the value of
- <c><![CDATA[name]]></c> in <c><![CDATA[term]]></c>. If no variable with the name
- <c><![CDATA[name]]></c> was found in <c><![CDATA[term]]></c>, or if <c><![CDATA[term]]></c> is
- not a valid Erlang term, NULL is returned.</p>
+ <c><![CDATA[name]]></c> in <c><![CDATA[term]]></c>. If no variable
+ with the name <c><![CDATA[name]]></c> is found in
+ <c><![CDATA[term]]></c>, or if <c><![CDATA[term]]></c> is
+ not a valid Erlang term, <c>NULL</c> is returned.</p>
</desc>
</func>
</funcs>
diff --git a/lib/erl_interface/doc/src/erl_format.xml b/lib/erl_interface/doc/src/erl_format.xml
index ce5163fbc7..9fe405d51c 100644
--- a/lib/erl_interface/doc/src/erl_format.xml
+++ b/lib/erl_interface/doc/src/erl_format.xml
@@ -28,51 +28,42 @@
<docno></docno>
<approved>Bjarne D&auml;cker</approved>
<checked>Torbj&ouml;rn T&ouml;rnkvist</checked>
- <date>961016</date>
+ <date>1996-10-16</date>
<rev>A</rev>
<file>erl_format.xml</file>
</header>
<lib>erl_format</lib>
- <libsummary>Create and Match Erlang Terms</libsummary>
+ <libsummary>Create and match Erlang terms.</libsummary>
<description>
- <p>This module contains two routines - one general function for
+ <p>This module contains two routines: one general function for
creating Erlang terms and one for pattern matching Erlang terms.</p>
</description>
+
<funcs>
<func>
- <name><ret>ETERM *</ret><nametext>erl_format(FormatStr, ... )</nametext></name>
- <fsummary>Creates an Erlang term.</fsummary>
+ <name><ret>ETERM *</ret><nametext>erl_format(FormatStr, ...)</nametext></name>
+ <fsummary>Create an Erlang term.</fsummary>
<type>
<v>char *FormatStr;</v>
</type>
<desc>
- <p>This is a general function for creating Erlang terms using
+ <p>A general function for creating Erlang terms using
a format specifier and a corresponding set of arguments, much
in the way <c><![CDATA[printf()]]></c> works.</p>
- <p><c><![CDATA[FormatStr]]></c> is a format specification string. The set
- of valid format specifiers is as follows:</p>
+ <p><c><![CDATA[FormatStr]]></c> is a format specification string.
+ The valid format specifiers are as follows:</p>
<list type="bulleted">
- <item>
- <p>~i - Integer</p>
- </item>
- <item>
- <p>~f - Floating point</p>
- </item>
- <item>
- <p>~a - Atom</p>
- </item>
- <item>
- <p>~s - String</p>
- </item>
- <item>
- <p>~w - Arbitrary Erlang term</p>
- </item>
+ <item><c>~i</c> - Integer</item>
+ <item><c>~f</c> - Floating point</item>
+ <item><c>~a</c> - Atom</item>
+ <item><c>~s</c> - String</item>
+ <item><c>~w</c> - Arbitrary Erlang term</item>
</list>
- <p>For each format specifier that appears in <c><![CDATA[FormatStr]]></c>,
+ <p>For each format specifier included in <c><![CDATA[FormatStr]]></c>,
there must be a corresponding argument following
- <c><![CDATA[FormatStr]]></c>. An Erlang term is built according to the
- <c><![CDATA[FormatStr]]></c> with values and Erlang terms substituted from
- the corresponding arguments and according to the individual
+ <c><![CDATA[FormatStr]]></c>. An Erlang term is built according to
+ <c><![CDATA[FormatStr]]></c> with values and Erlang terms substituted
+ from the corresponding arguments, and according to the individual
format specifiers. For example:</p>
<code type="none"><![CDATA[
erl_format("[{name,~a},{age,~i},{data,~w}]",
@@ -80,34 +71,41 @@ erl_format("[{name,~a},{age,~i},{data,~w}]",
21,
erl_format("[{adr,~s,~i}]","E-street",42));
]]></code>
- <p>This will create an <c><![CDATA[(ETERM *)]]></c> structure corresponding
- to the Erlang term:
+ <p>This creates an <c><![CDATA[(ETERM *)]]></c> structure corresponding
+ to the Erlang term
<c><![CDATA[[{name,madonna},{age,21},{data,[{adr,"E-street",42}]}]]]></c></p>
- <p>The function returns an Erlang term, or NULL if
- <c><![CDATA[FormatStr]]></c> does not describe a valid Erlang term.</p>
+ <p>The function returns an Erlang term, or <c>NULL</c> if
+ <c><![CDATA[FormatStr]]></c> does not describe a valid Erlang
+ term.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>erl_match(Pattern, Term)</nametext></name>
- <fsummary>Performs pattern matching.</fsummary>
+ <fsummary>Perform pattern matching.</fsummary>
+ <marker id="erl_match"/>
<type>
<v>ETERM *Pattern,*Term;</v>
</type>
<desc>
<p>This function is used to perform pattern matching similar
- to that done in Erlang. Refer to an Erlang manual for matching
- rules and more examples.</p>
- <p><c><![CDATA[Pattern]]></c> is an Erlang term, possibly containing unbound
- variables. </p>
- <p><c><![CDATA[Term]]></c> is an Erlang term that we wish to match against
- <c><![CDATA[Pattern]]></c>.</p>
- <p><c><![CDATA[Term]]></c> and <c><![CDATA[Pattern]]></c> are compared, and any
- unbound variables in <c><![CDATA[Pattern]]></c> are bound to corresponding
- values in <c><![CDATA[Term]]></c>. </p>
- <p>If <c><![CDATA[Term]]></c> and <c><![CDATA[Pattern]]></c> can be matched, the
- function returns a non-zero value and binds any unbound
- variables in <c><![CDATA[Pattern]]></c>. If <c><![CDATA[Term]]></c> <c><![CDATA[Pattern]]></c> do
- not match, the function returns 0. For example:</p>
+ to that done in Erlang. For matching rules and more exemples, see
+ section <seealso marker="doc/reference_manual#patterns">
+ Pattern Matching</seealso> in the Erlang Reference Manual.</p>
+ <list type="bulleted">
+ <item><c><![CDATA[Pattern]]></c> is an Erlang term, possibly
+ containing unbound variables.</item>
+ <item><c><![CDATA[Term]]></c> is an Erlang term that we wish to match
+ against <c><![CDATA[Pattern]]></c>.</item>
+ </list>
+ <p><c><![CDATA[Term]]></c> and <c><![CDATA[Pattern]]></c> are compared
+ and any unbound variables in <c><![CDATA[Pattern]]></c> are bound to
+ corresponding values in <c><![CDATA[Term]]></c>.</p>
+ <p>If <c><![CDATA[Term]]></c> and <c><![CDATA[Pattern]]></c> can be
+ matched, the function returns a non-zero value and binds any unbound
+ variables in <c><![CDATA[Pattern]]></c>. If <c><![CDATA[Term]]></c>
+ and <c><![CDATA[Pattern]]></c> do
+ not match, <c>0</c> is returned. For example:</p>
<code type="none"><![CDATA[
ETERM *term, *pattern, *pattern2;
term1 = erl_format("{14,21}");
diff --git a/lib/erl_interface/doc/src/erl_global.xml b/lib/erl_interface/doc/src/erl_global.xml
index 69f303722d..fa565ba56c 100644
--- a/lib/erl_interface/doc/src/erl_global.xml
+++ b/lib/erl_interface/doc/src/erl_global.xml
@@ -28,91 +28,100 @@
<docno></docno>
<approved>Gordon Beaton</approved>
<checked>Gordon Beaton</checked>
- <date>980703</date>
+ <date>1998-07-03</date>
<rev>A</rev>
<file>erl_global.xml</file>
</header>
<lib>erl_global</lib>
- <libsummary>Access globally registered names</libsummary>
+ <libsummary>Access globally registered names.</libsummary>
<description>
<p>This module provides support for registering, looking
- up and unregistering names in the Erlang Global module. For more
- information, see the description of Global in the reference manual.</p>
- <p>Note that the functions below perform an RPC using an open file
+ up, and unregistering names in the <c>global</c> module.
+ For more information, see
+ <seealso marker="kernel:global"><c>kernel:global</c></seealso>.</p>
+
+ <p>Notice that the functions below perform an RPC using an open file
descriptor provided by the caller. This file descriptor must
- not be used for other traffic during the global operation or the
- function may receive unexpected data and fail.</p>
+ not be used for other traffic during the global operation, as the
+ function can then receive unexpected data and fail.</p>
</description>
+
<funcs>
<func>
<name><ret>char **</ret><nametext>erl_global_names(fd,count)</nametext></name>
- <fsummary>Obtain list of Global names.</fsummary>
+ <fsummary>Obtain list of global names.</fsummary>
+ <marker id="erl_global_names"/>
<type>
<v>int fd;</v>
<v>int *count;</v>
</type>
<desc>
- <p>Retrieve a list of all known global names.
- </p>
- <p><c><![CDATA[fd]]></c> is an open descriptor to an Erlang connection.
- </p>
- <p><c><![CDATA[count]]></c> is the address of an integer, or NULL. If
- <c><![CDATA[count]]></c> is not NULL, it will be set by the function to
- the number of names found.
- </p>
+ <p>Retrieves a list of all known global names.</p>
+ <list type="bulleted">
+ <item><c><![CDATA[fd]]></c> is an open descriptor to an Erlang
+ connection.</item>
+ <item><c><![CDATA[count]]></c> is the address of an integer, or
+ <c>NULL</c>. If <c><![CDATA[count]]></c> is not <c>NULL</c>, it is
+ set by the function to the number of names found.</item>
+ </list>
<p>On success, the function returns an array of strings, each
- containing a single registered name, and sets <c><![CDATA[count]]></c> to
+ containing a single registered name, and sets
+ <c><![CDATA[count]]></c> to
the number of names found. The array is terminated
- by a single NULL pointer. On failure, the function returns
- NULL and <c><![CDATA[count]]></c> is not modified.
- </p>
+ by a single <c>NULL</c> pointer. On failure, the function returns
+ <c>NULL</c> and <c><![CDATA[count]]></c> is not modified.</p>
<note>
<p>It is the caller's responsibility to free the array
afterwards. It has been allocated by the function with a
- single call to <c><![CDATA[malloc()]]></c>, so a single <c><![CDATA[free()]]></c> is
- all that is necessary.</p>
+ single call to <c><![CDATA[malloc()]]></c>, so a single
+ <c><![CDATA[free()]]></c> is all that is necessary.</p>
</note>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>erl_global_register(fd,name,pid)</nametext></name>
- <fsummary>Register a name in Global.</fsummary>
+ <fsummary>Register a name in global.</fsummary>
<type>
<v>int fd;</v>
<v>const char *name;</v>
<v>ETERM *pid;</v>
</type>
<desc>
- <p>This function registers a name in Global.
- </p>
- <p><c><![CDATA[fd]]></c> is an open descriptor to an Erlang connection.
- </p>
- <p><c><![CDATA[name]]></c> is the name to register in Global.
- </p>
- <p><c><![CDATA[pid]]></c> is the pid that should be associated with
- <c><![CDATA[name]]></c>. This is the value that Global will return when
- processes request the location of <c><![CDATA[name]]></c>.
- </p>
- <p>The function returns 0 on success, or -1 on failure.</p>
+ <p>Registers a name in <c>global</c>.</p>
+ <list type="bulleted">
+ <item><c><![CDATA[fd]]></c> is an open descriptor to an Erlang
+ connection.</item>
+ <item><c><![CDATA[name]]></c> is the name to register in
+ <c>global</c>.</item>
+ <item><c><![CDATA[pid]]></c> is the pid that is to be associated with
+ <c><![CDATA[name]]></c>. This value is returned by <c>global</c>
+ when processes request the location of <c><![CDATA[name]]></c>.
+ </item>
+ </list>
+ <p>Returns <c>0</c> on success, otherwise <c>-1</c>.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>erl_global_unregister(fd,name)</nametext></name>
- <fsummary>Unregister a name in Global.</fsummary>
+ <fsummary>Unregister a name from global.</fsummary>
<type>
<v>int fd;</v>
<v>const char *name;</v>
</type>
<desc>
- <p>This function unregisters a name from Global.
- </p>
- <p><c><![CDATA[fd]]></c> is an open descriptor to an Erlang connection.
- </p>
- <p><c><![CDATA[name]]></c> is the name to unregister from Global.
- </p>
- <p>The function returns 0 on success, or -1 on failure.</p>
+ <p>Unregisters a name from <c>global</c>.</p>
+ <list type="bulleted">
+ <item><c><![CDATA[fd]]></c> is an open descriptor to an Erlang
+ connection.</item>
+ <item><c><![CDATA[name]]></c> is the name to unregister from
+ <c>global</c>.</item>
+ </list>
+ <p>Returns <c>0</c> on success, otherwise <c>-1</c>.</p>
</desc>
</func>
+
<func>
<name><ret>ETERM *</ret><nametext>erl_global_whereis(fd,name,node)</nametext></name>
<fsummary>Look up a name in global.</fsummary>
@@ -122,19 +131,22 @@
<v>char *node;</v>
</type>
<desc>
- <p><c><![CDATA[fd]]></c> is an open descriptor to an Erlang connection.
- </p>
- <p><c><![CDATA[name]]></c> is the name that is to be looked up in Global.
- </p>
- <p>If <c><![CDATA[node]]></c> is not NULL, it is a pointer to a buffer
- where the function can fill in the name of the node where
- <c><![CDATA[name]]></c> is found. <c><![CDATA[node]]></c> can be passed directly to
- <c><![CDATA[erl_connect()]]></c> if necessary.
- </p>
- <p>On success, the function returns an Erlang Pid containing the address
- of the given name, and node will be initialized to
- the nodename where <c><![CDATA[name]]></c> is found. On failure NULL will be
- returned and <c><![CDATA[node]]></c> will not be modified.</p>
+ <p>Looks up a name in <c>global</c>.</p>
+ <list type="bulleted">
+ <item><c><![CDATA[fd]]></c> is an open descriptor to an Erlang
+ connection.</item>
+ <item><c><![CDATA[name]]></c> is the name that is to be looked up in
+ <c>global</c>.</item>
+ </list>
+ <p>If <c><![CDATA[node]]></c> is not <c>NULL</c>, it is a pointer to a
+ buffer where the function can fill in the name of the node where
+ <c><![CDATA[name]]></c> is found. <c><![CDATA[node]]></c> can be
+ passed directly to <c><![CDATA[erl_connect()]]></c> if necessary.</p>
+ <p>On success, the function returns an Erlang pid containing the address
+ of the specified name, and the node is initialized to
+ the node name where <c><![CDATA[name]]></c> is found. On failure,
+ <c>NULL</c> is returned and <c><![CDATA[node]]></c> is not
+ modified.</p>
</desc>
</func>
</funcs>
diff --git a/lib/erl_interface/doc/src/erl_malloc.xml b/lib/erl_interface/doc/src/erl_malloc.xml
index ba1f59a492..28de9dfa88 100644
--- a/lib/erl_interface/doc/src/erl_malloc.xml
+++ b/lib/erl_interface/doc/src/erl_malloc.xml
@@ -28,172 +28,177 @@
<docno></docno>
<approved>Bjarne D&auml;cker</approved>
<checked>Torbj&ouml;rn T&ouml;rnkvist</checked>
- <date>980703</date>
+ <date>1998-07-03</date>
<rev>A</rev>
<file>erl_malloc.xml</file>
</header>
<lib>erl_malloc</lib>
- <libsummary>Memory Allocation Functions</libsummary>
+ <libsummary>Memory allocation functions.</libsummary>
<description>
<p>This module provides functions for allocating and deallocating
memory.</p>
</description>
+
<funcs>
<func>
<name><ret>ETERM *</ret><nametext>erl_alloc_eterm(etype)</nametext></name>
- <fsummary>Allocates an ETERM structure.</fsummary>
+ <fsummary>Allocate an ETERM structure.</fsummary>
<type>
<v>unsigned char etype;</v>
</type>
<desc>
- <p>This function allocates an <c><![CDATA[(ETERM)]]></c> structure.
- Specify <c><![CDATA[etype]]></c> as one of the following constants:</p>
+ <p>Allocates an <c><![CDATA[(ETERM)]]></c> structure.</p>
+ <p>Specify <c><![CDATA[etype]]></c> as one of the following
+ constants:</p>
<list type="bulleted">
- <item>
- <p>ERL_INTEGER</p>
+ <item><c>ERL_INTEGER</c>
</item>
- <item>
- <p>ERL_U_INTEGER <c><![CDATA[/* unsigned integer */]]></c></p>
+ <item><c>ERL_U_INTEGER</c> (unsigned integer)
</item>
- <item>
- <p>ERL_ATOM</p>
+ <item><c>ERL_ATOM</c>
</item>
- <item>
- <p>ERL_PID <c><![CDATA[/* Erlang process identifier */]]></c></p>
+ <item><c>ERL_PID</c> (Erlang process identifier)
</item>
- <item>
- <p>ERL_PORT</p>
+ <item><c>ERL_PORT</c>
</item>
- <item>
- <p>ERL_REF <c><![CDATA[/* Erlang reference */]]></c></p>
+ <item><c>ERL_REF</c> (Erlang reference)
</item>
- <item>
- <p>ERL_LIST</p>
+ <item><c>ERL_LIST</c>
</item>
- <item>
- <p>ERL_EMPTY_LIST</p>
+ <item><c>ERL_EMPTY_LIST</c>
</item>
- <item>
- <p>ERL_TUPLE</p>
+ <item><c>ERL_TUPLE</c>
</item>
- <item>
- <p>ERL_BINARY</p>
+ <item><c>ERL_BINARY</c>
</item>
- <item>
- <p>ERL_FLOAT</p>
+ <item><c>ERL_FLOAT</c>
</item>
- <item>
- <p>ERL_VARIABLE</p>
+ <item><c>ERL_VARIABLE</c>
</item>
- <item>
- <p>ERL_SMALL_BIG <c><![CDATA[/* bignum */]]></c></p>
+ <item><c>ERL_SMALL_BIG</c> (bignum)
</item>
- <item>
- <p>ERL_U_SMALL_BIG <c><![CDATA[/* bignum */]]></c></p>
+ <item><c>ERL_U_SMALL_BIG</c> (bignum)
</item>
</list>
- <p><c><![CDATA[ERL_SMALL_BIG]]></c> and <c><![CDATA[ERL_U_SMALL_BIG]]></c> are for
- creating Erlang <c><![CDATA[bignums]]></c>, which can contain integers of
- arbitrary size. The size of an integer in Erlang is machine
- dependent, but in general any integer larger than 2^28
- requires a bignum.</p>
+ <p><c><![CDATA[ERL_SMALL_BIG]]></c> and
+ <c><![CDATA[ERL_U_SMALL_BIG]]></c> are for
+ creating Erlang <c><![CDATA[bignums]]></c>, which can contain integers
+ of any size. The size of an integer in Erlang is machine-dependent,
+ but any integer &gt; 2^28 requires a bignum.</p>
</desc>
</func>
+
<func>
<name><ret>void</ret><nametext>erl_eterm_release(void)</nametext></name>
- <fsummary>Clears the ETERM freelist.</fsummary>
+ <fsummary>Clear the ETERM freelist.</fsummary>
<desc>
- <p>Clears the
- freelist, where blocks are placed when they are
+ <p>Clears the freelist, where blocks are placed when they are
released by <c><![CDATA[erl_free_term()]]></c> and
- <c><![CDATA[erl_free_compound()]]></c>. </p>
+ <c><![CDATA[erl_free_compound()]]></c>.</p>
</desc>
</func>
+
<func>
<name><ret>void</ret><nametext>erl_eterm_statistics(allocated, freed)</nametext></name>
- <fsummary>Reports term allocation statistics.</fsummary>
+ <fsummary>Report term allocation statistics.</fsummary>
<type>
<v>long *allocated;</v>
<v>long *freed;</v>
</type>
<desc>
- <p><c><![CDATA[allocated]]></c> and <c><![CDATA[freed]]></c> are initialized to
+ <p>Reports term allocation statistics.</p>
+ <p><c><![CDATA[allocated]]></c> and <c><![CDATA[freed]]></c> are
+ initialized to
contain information about the fix-allocator used to allocate
- ETERM components. <c><![CDATA[allocated]]></c> is the number of blocks
- currently allocated to ETERM objects. <c><![CDATA[freed]]></c> is the
- length of the freelist, where blocks are placed when they are
- released by <c><![CDATA[erl_free_term()]]></c> and
- <c><![CDATA[erl_free_compound()]]></c>. </p>
+ <c>ETERM</c> components.</p>
+ <list type="bulleted">
+ <item>
+ <p><c><![CDATA[allocated]]></c> is the number of blocks currently
+ allocated to <c>ETERM</c> objects.</p>
+ </item>
+ <item>
+ <p><c><![CDATA[freed]]></c> is the length of the freelist, where
+ blocks are placed when they are
+ released by <c><![CDATA[erl_free_term()]]></c> and
+ <c><![CDATA[erl_free_compound()]]></c>.</p>
+ </item>
+ </list>
</desc>
</func>
+
<func>
<name><ret>void</ret><nametext>erl_free(ptr)</nametext></name>
- <fsummary>Frees some memory.</fsummary>
+ <fsummary>Free some memory.</fsummary>
<type>
<v>void *ptr;</v>
</type>
<desc>
- <p>This function calls the standard
- <c><![CDATA[free()]]></c> function. </p>
+ <p>Calls the standard
+ <c><![CDATA[free()]]></c> function.</p>
</desc>
</func>
+
<func>
<name><ret>void</ret><nametext>erl_free_array(array, size)</nametext></name>
- <fsummary>Frees an array of ETERM structures.</fsummary>
+ <fsummary>Free an array of ETERM structures.</fsummary>
<type>
<v>ETERM **array;</v>
<v>int size;</v>
</type>
<desc>
- <p>This function frees an array of Erlang terms.</p>
- <p><c><![CDATA[array]]></c> is an array of ETERM* objects.
- </p>
- <p><c><![CDATA[size]]></c> is the number of terms in the array.</p>
+ <p>Frees an array of Erlang terms.</p>
+ <list type="bulleted">
+ <item><c><![CDATA[array]]></c> is an array of ETERM* objects.</item>
+ <item><c><![CDATA[size]]></c> is the number of terms in the array.
+ </item>
+ </list>
</desc>
</func>
+
<func>
<name><ret>void</ret><nametext>erl_free_compound(t)</nametext></name>
- <fsummary>Frees an array of ETERM structures.</fsummary>
+ <fsummary>Free an array of ETERM structures.</fsummary>
<type>
<v>ETERM *t;</v>
</type>
<desc>
<p>Normally it is the programmer's responsibility to free each
Erlang term that has been returned from any of the
- <c><![CDATA[erl_interface]]></c> functions. However since many of the
+ <c><![CDATA[Erl_Interface]]></c> functions. However, as many of the
functions that build new Erlang terms in fact share objects
- with other existing terms, it may be difficult for the
- programmer to maintain pointers to all such terms in order to
- free them individually.
- </p>
- <p><c><![CDATA[erl_free_compound()]]></c> will recursively free all of the
- sub-terms associated with a given Erlang term, regardless of
- whether we are still holding pointers to the sub-terms.
- </p>
- <p>There is an example in the User Manual under "Building
- Terms and Patterns"
- </p>
+ with other existing terms, it can be difficult for the
+ programmer to maintain pointers to all such terms to
+ free them individually.</p>
+ <p><c><![CDATA[erl_free_compound()]]></c> recursively frees all of the
+ subterms associated with a specified Erlang term, regardless of
+ whether we are still holding pointers to the subterms.</p>
+ <p>For an example, see section
+ <seealso marker="building terms and patterns">Building Terms and
+ Patterns"></seealso> in the User's Guide.</p>
</desc>
</func>
+
<func>
<name><ret>void</ret><nametext>erl_free_term(t)</nametext></name>
- <fsummary>Frees an ETERM structure.</fsummary>
+ <fsummary>Free an ETERM structure.</fsummary>
+ <marker id="erl_free_term"/>
<type>
<v>ETERM *t;</v>
</type>
<desc>
- <p>Use this function to free an Erlang term.</p>
+ <p>Frees an Erlang term.</p>
</desc>
</func>
+
<func>
<name><ret>void</ret><nametext>erl_malloc(size)</nametext></name>
- <fsummary>Allocates some memory.</fsummary>
+ <fsummary>Allocate some memory.</fsummary>
<type>
<v>long size;</v>
</type>
<desc>
- <p>This function calls the standard
- <c><![CDATA[malloc()]]></c> function. </p>
+ <p>Calls the standard
+ <c><![CDATA[malloc()]]></c> function.</p>
</desc>
</func>
</funcs>
diff --git a/lib/erl_interface/doc/src/erl_marshal.xml b/lib/erl_interface/doc/src/erl_marshal.xml
index c70bdb53e1..30b7281a51 100644
--- a/lib/erl_interface/doc/src/erl_marshal.xml
+++ b/lib/erl_interface/doc/src/erl_marshal.xml
@@ -28,244 +28,240 @@
<docno></docno>
<approved>Bjarne D&auml;cker</approved>
<checked>Torbj&ouml;rn T&ouml;rnkvist</checked>
- <date>980703</date>
+ <date>1998-07-03</date>
<rev>A</rev>
<file>erl_marshal.xml</file>
</header>
<lib>erl_marshal</lib>
- <libsummary>Encoding and Decoding of Erlang terms</libsummary>
+ <libsummary>Encoding and decoding of Erlang terms.</libsummary>
<description>
<p>This module contains functions for encoding Erlang terms into
a sequence of bytes, and for decoding Erlang terms from a
sequence of bytes.</p>
</description>
+
<funcs>
<func>
<name><ret>int</ret><nametext>erl_compare_ext(bufp1, bufp2)</nametext></name>
- <fsummary>Compares encoded byte sequences.</fsummary>
+ <fsummary>Compare encoded byte sequences.</fsummary>
<type>
<v>unsigned char *bufp1,*bufp2;</v>
</type>
<desc>
- <p>This function compares two encoded terms.
- </p>
- <p><c><![CDATA[bufp1]]></c> is a buffer containing an encoded Erlang
- term term1.
- </p>
- <p><c><![CDATA[bufp2]]></c> is a buffer containing an encoded Erlang
- term term2.
- </p>
- <p>The function returns 0 if the terms are equal, -1 if term1
- is less than term2, or 1 if term2 is less than term1.
- </p>
+ <p>Compares two encoded terms.</p>
+ <list type="bulleted">
+ <item><c><![CDATA[bufp1]]></c> is a buffer containing an encoded
+ Erlang term term1.</item>
+ <item><c><![CDATA[bufp2]]></c> is a buffer containing an encoded
+ Erlang term term2.</item>
+ </list>
+ <p>Returns <c>0</c> if the terms are equal, <c>-1</c> if
+ <c>term1</c> &lt; <c>term2</c>, or <c>1</c> if <c>term2</c> &lt;
+ term1.</p>
</desc>
</func>
+
<func>
<name><ret>ETERM *</ret><nametext>erl_decode(bufp)</nametext></name>
<name><ret>ETERM *</ret><nametext>erl_decode_buf(bufpp)</nametext></name>
- <fsummary>Converts a term from Erlang external format.</fsummary>
+ <fsummary>Convert a term from Erlang external format.</fsummary>
<type>
<v>unsigned char *bufp;</v>
<v>unsigned char **bufpp;</v>
</type>
<desc>
- <p><c><![CDATA[erl_decode()]]></c> and <c><![CDATA[erl_decode_buf()]]></c> decode
+ <p><c><![CDATA[erl_decode()]]></c> and
+ <c><![CDATA[erl_decode_buf()]]></c> decode
the contents of a buffer and return the corresponding
- Erlang term. <c><![CDATA[erl_decode_buf()]]></c> provides a simple
+ Erlang term. <c><![CDATA[erl_decode_buf()]]></c> provides a simple
mechanism for dealing with several encoded terms stored
consecutively in the buffer.</p>
- <p><c><![CDATA[bufp]]></c> is a pointer to a buffer containing one or
- more encoded Erlang terms.
- </p>
- <p><c><![CDATA[bufpp]]></c> is the address of a buffer pointer. The buffer
- contains one or more consecutively encoded Erlang terms.
- Following a successful call to <c><![CDATA[erl_decode_buf()]]></c>,
- <c><![CDATA[bufpp]]></c> will be updated so that it points to the next
- encoded term.
- </p>
+ <list type="bulleted">
+ <item>
+ <p><c><![CDATA[bufp]]></c> is a pointer to a buffer containing one
+ or more encoded Erlang terms.</p>
+ </item>
+ <item>
+ <p><c><![CDATA[bufpp]]></c> is the address of a buffer pointer. The
+ buffer contains one or more consecutively encoded Erlang terms.
+ Following a successful call to
+ <c><![CDATA[erl_decode_buf()]]></c>, <c><![CDATA[bufpp]]></c> is
+ updated so that it points to the next encoded term.</p>
+ </item>
+ </list>
<p><c><![CDATA[erl_decode()]]></c> returns an Erlang term
- corresponding to the contents of <c><![CDATA[bufp]]></c> on success, or
- NULL on failure. <c><![CDATA[erl_decode_buf()]]></c> returns an Erlang
+ corresponding to the contents of <c><![CDATA[bufp]]></c> on success,
+ otherwise <c>NULL</c>. <c><![CDATA[erl_decode_buf()]]></c>
+ returns an Erlang
term corresponding to the first of the consecutive terms in
- <c><![CDATA[bufpp]]></c> and moves <c><![CDATA[bufpp]]></c> forward to point to the
+ <c><![CDATA[bufpp]]></c> and moves <c><![CDATA[bufpp]]></c> forward
+ to point to the
next term in the buffer. On failure, each of the functions
- returns NULL.
- </p>
+ return <c>NULL</c>.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>erl_encode(term, bufp)</nametext></name>
<name><ret>int</ret><nametext>erl_encode_buf(term, bufpp)</nametext></name>
- <fsummary>Converts a term into Erlang external format.</fsummary>
+ <fsummary>Convert a term into Erlang external format.</fsummary>
<type>
<v>ETERM *term;</v>
<v>unsigned char *bufp;</v>
<v>unsigned char **bufpp;</v>
</type>
<desc>
- <p><c><![CDATA[erl_encode()]]></c> and <c><![CDATA[erl_encode_buf()]]></c> encode
+ <p><c><![CDATA[erl_encode()]]></c> and
+ <c><![CDATA[erl_encode_buf()]]></c> encode
Erlang terms into external format for storage or transmission.
<c><![CDATA[erl_encode_buf()]]></c> provides a simple mechanism for
- encoding several terms consecutively in the same
- buffer.
- </p>
- <p><c>term</c> is an Erlang term to be encoded.
- </p>
- <p><c>bufp</c> is a pointer to a buffer containing one or
- more encoded Erlang terms.
- </p>
- <p><c>bufpp</c> is a pointer to a pointer to a buffer
- containing one or more consecutively encoded Erlang terms.
- Following a successful call to <c><![CDATA[erl_encode_buf()]]></c>,
- <c>bufpp</c> will be updated so that it points to the
- position for the next encoded term.
- </p>
- <p>
- These functions returns the number of bytes written to buffer
- if successful, otherwise returns 0.
- </p>
- <p>Note that no bounds checking is done on the buffer. It is
- the caller's responsibility to make sure that the buffer is
+ encoding several terms consecutively in the same buffer.</p>
+ <list type="bulleted">
+ <item>
+ <p><c>term</c> is an Erlang term to be encoded.</p>
+ </item>
+ <item>
+ <p><c>bufp</c> is a pointer to a buffer containing one or
+ more encoded Erlang terms.</p>
+ </item>
+ <item>
+ <p><c>bufpp</c> is a pointer to a pointer to a buffer
+ containing one or more consecutively encoded Erlang terms.
+ Following a successful call to
+ <c><![CDATA[erl_encode_buf()]]></c>, <c>bufpp</c> is updated so
+ that it points to the
+ position for the next encoded term.</p>
+ </item>
+ </list>
+ <p>These functions return the number of bytes written to buffer
+ on success, otherwise <c>0</c>.</p>
+ <p>Notice that no bounds checking is done on the buffer. It is
+ the caller's responsibility to ensure that the buffer is
large enough to hold the encoded terms. You can either use a
- static buffer that is large enough to hold the terms you
- expect to need in your program, or use <c><![CDATA[erl_term_len()]]></c>
- to determine the exact requirements for a given term.
- </p>
+ static buffer that is large enough to hold the terms you expect
+ to need in your program, or use <c><![CDATA[erl_term_len()]]></c>
+ to determine the exact requirements for a given term.</p>
<p>The following can help you estimate the buffer
- requirements for a term. Note that this information is
- implementation specific, and may change in future versions.
- If you are unsure, use <c><![CDATA[erl_term_len()]]></c>.
- </p>
+ requirements for a term. Notice that this information is
+ implementation-specific, and can change in future versions.
+ If you are unsure, use <c><![CDATA[erl_term_len()]]></c>.</p>
<p>Erlang terms are encoded with a 1 byte tag that
identifies the type of object, a 2- or 4-byte length field,
- and then the data itself. Specifically:
- </p>
+ and then the data itself. Specifically:</p>
<taglist>
<tag><c><![CDATA[Tuples]]></c></tag>
- <item>need 5 bytes, plus the space for each element.</item>
+ <item>Need 5 bytes, plus the space for each element.</item>
<tag><c><![CDATA[Lists]]></c></tag>
- <item>need 5 bytes, plus the space for each element, and 1
- additional byte for the empty list at the end.</item>
+ <item>Need 5 bytes, plus the space for each element, and 1
+ more byte for the empty list at the end.</item>
<tag><c><![CDATA[Strings and atoms]]></c></tag>
- <item>need 3 bytes, plus 1 byte for each character (the
- terminating 0 is not encoded). Really long strings (more
- than 64k characters) are encoded as lists. Atoms cannot
- contain more than 256 characters.</item>
+ <item>Need 3 bytes, plus 1 byte for each character (the
+ terminating 0 is not encoded). Really long strings (more
+ than 64k characters) are encoded as lists. Atoms cannot
+ contain more than 256 characters.</item>
<tag><c><![CDATA[Integers]]></c></tag>
- <item>need 5 bytes.</item>
+ <item>Need 5 bytes.</item>
<tag><c><![CDATA[Characters]]></c></tag>
- <item>(integers &lt; 256) need 2 bytes.</item>
+ <item>(Integers &lt; 256) need 2 bytes.</item>
<tag><c><![CDATA[Floating point numbers]]></c></tag>
- <item>need 32 bytes.</item>
+ <item>Need 32 bytes.</item>
<tag><c><![CDATA[Pids]]></c></tag>
- <item>need 10 bytes, plus the space for the node name, which
- is an atom.</item>
+ <item>Need 10 bytes, plus the space for the node name, which
+ is an atom.</item>
<tag><c><![CDATA[Ports and Refs]]></c></tag>
- <item>need 6 bytes, plus the space for the node name, which
- is an atom.</item>
+ <item>Need 6 bytes, plus the space for the node name, which
+ is an atom.</item>
</taglist>
- <p>The total space required will be the result calculated
- from the information above, plus 1 additional byte for a
- version identifier.
- </p>
+ <p>The total space required is the result calculated
+ from the information above, plus 1 more byte for a
+ version identifier.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>erl_ext_size(bufp)</nametext></name>
- <fsummary>Counts elements in encoded term.</fsummary>
+ <fsummary>Count elements in encoded term.</fsummary>
<type>
<v>unsigned char *bufp;</v>
</type>
<desc>
- <p>This function returns the number of elements in an
- encoded term.</p>
+ <p>Returns the number of elements in an encoded term.</p>
</desc>
</func>
+
<func>
<name><ret>unsigned char</ret><nametext>erl_ext_type(bufp)</nametext></name>
- <fsummary>Determines type of an encoded byte sequence.</fsummary>
+ <fsummary>Determine type of an encoded byte sequence.</fsummary>
<type>
<v>unsigned char *bufp;</v>
</type>
<desc>
- <p>This function identifies and returns the type of Erlang term encoded
- in a buffer. It will skip a trailing <em>magic</em> identifier.
- Returns <c><![CDATA[0]]></c> if the type can't be determined or one of</p>
+ <p>Identifies and returns the type of Erlang term encoded
+ in a buffer. It skips a trailing <em>magic</em> identifier.</p>
+ <p>Returns <c><![CDATA[0]]></c> if the type cannot be determined or
+ one of:</p>
<list type="bulleted">
- <item>
- <p>ERL_INTEGER</p>
+ <item><c>ERL_INTEGER</c>
</item>
- <item>
- <p>ERL_ATOM</p>
+ <item><c>ERL_ATOM</c>
</item>
- <item>
- <p>ERL_PID <c><![CDATA[/* Erlang process identifier */]]></c></p>
+ <item><c>ERL_PID</c> (Erlang process identifier)
</item>
- <item>
- <p>ERL_PORT</p>
+ <item><c>ERL_PORT</c>
</item>
- <item>
- <p>ERL_REF <c><![CDATA[/* Erlang reference */]]></c></p>
+ <item><c>ERL_REF</c> (Erlang reference)
</item>
- <item>
- <p>ERL_EMPTY_LIST</p>
+ <item><c>ERL_EMPTY_LIST</c>
</item>
- <item>
- <p>ERL_LIST</p>
+ <item><c>ERL_LIST</c>
</item>
- <item>
- <p>ERL_TUPLE</p>
+ <item><c>ERL_TUPLE</c>
</item>
- <item>
- <p>ERL_FLOAT</p>
+ <item><c>ERL_FLOAT</c>
</item>
- <item>
- <p>ERL_BINARY</p>
+ <item><c>ERL_BINARY</c>
</item>
- <item>
- <p>ERL_FUNCTION</p>
+ <item><c>ERL_FUNCTION</c>
</item>
</list>
</desc>
</func>
+
<func>
<name><ret>unsigned char *</ret><nametext>erl_peek_ext(bufp, pos)</nametext></name>
- <fsummary>Steps over encoded term.</fsummary>
+ <fsummary>Step over encoded term.</fsummary>
<type>
<v>unsigned char *bufp;</v>
<v>int pos;</v>
</type>
<desc>
<p>This function is used for stepping over one or more
- encoded terms in a buffer, in order to directly access a
- later term.
- </p>
- <p><c><![CDATA[bufp]]></c> is a pointer to a buffer containing one or
- more encoded Erlang terms.
- </p>
- <p><c><![CDATA[pos]]></c> indicates how many terms to step over in the
- buffer.
- </p>
- <p>The function returns a pointer to a sub-term that can be
- used in a subsequent call to <c><![CDATA[erl_decode()]]></c> in order to retrieve
- the term at that position. If there is no term, or <c><![CDATA[pos]]></c>
- would exceed the size of the terms in the buffer, NULL is returned.
- </p>
+ encoded terms in a buffer, to directly access later term.</p>
+ <list type="bulleted">
+ <item><c><![CDATA[bufp]]></c> is a pointer to a buffer containing one
+ or more encoded Erlang terms.</item>
+ <item><c><![CDATA[pos]]></c> indicates how many terms to step over in
+ the buffer.</item>
+ </list>
+ <p>Returns a pointer to a subterm that can be
+ used in a later call to <c><![CDATA[erl_decode()]]></c> to retrieve
+ the term at that position. If there is no term, or
+ <c><![CDATA[pos]]></c> would exceed the size of the terms in the
+ buffer, <c>NULL</c> is returned.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>erl_term_len(t)</nametext></name>
- <fsummary>Determines encoded size of term.</fsummary>
+ <fsummary>Determine encoded size of term.</fsummary>
<type>
<v>ETERM *t;</v>
</type>
<desc>
- <p>This function determines the buffer space that would be
+ <p>Determines the buffer space that would be
needed by <c><![CDATA[t]]></c> if it were encoded into Erlang external
- format by <c><![CDATA[erl_encode()]]></c>.
- </p>
- <p>The size in bytes is returned.
- </p>
+ format by <c><![CDATA[erl_encode()]]></c>.</p>
+ <p>Returns the size in bytes.</p>
</desc>
</func>
</funcs>
diff --git a/lib/erl_interface/doc/src/part.xml b/lib/erl_interface/doc/src/part.xml
index d044e2b981..3b761df221 100644
--- a/lib/erl_interface/doc/src/part.xml
+++ b/lib/erl_interface/doc/src/part.xml
@@ -22,7 +22,7 @@
</legalnotice>
- <title>EI User's Guide</title>
+ <title>Erl_Interface User's Guide</title>
<prepared>Gordon Beaton</prepared>
<docno></docno>
<date>1998-11-30</date>
diff --git a/lib/erl_interface/doc/src/ref_man.xml b/lib/erl_interface/doc/src/ref_man.xml
index e23f00956a..1e20637cb7 100644
--- a/lib/erl_interface/doc/src/ref_man.xml
+++ b/lib/erl_interface/doc/src/ref_man.xml
@@ -21,7 +21,7 @@
limitations under the License.
</legalnotice>
- <title>Erl_Interface Command Reference</title>
+ <title>Erl_Interface Reference Manual</title>
<prepared>Gordon Beaton</prepared>
<docno></docno>
<date>1998-11.30</date>
@@ -29,17 +29,6 @@
<file>ref_man.xml</file>
</header>
<description>
- <p>The <c>ei</c> and <c>erl_interface</c> are <c>C</c> interface libraries for
- communication with <c>Erlang</c>.</p>
- <note>
- <p>By default, the <c>ei</c> and <c>erl_interface</c> libraries are only guaranteed
- to be compatible with other Erlang/OTP components from the same
- release as the libraries themself. See the documentation of the
- <seealso marker="ei#ei_set_compat_rel">ei_set_compat_rel()</seealso> and
- <seealso marker="erl_eterm#erl_set_compat_rel">erl_set_compat_rel()</seealso>
- functions on how to communicate with Erlang/OTP components from earlier
- releases.</p>
- </note>
</description>
<xi:include href="ei.xml"/>
<xi:include href="ei_connect.xml"/>
diff --git a/lib/erl_interface/doc/src/registry.xml b/lib/erl_interface/doc/src/registry.xml
index fd3e29c30f..022af85149 100644
--- a/lib/erl_interface/doc/src/registry.xml
+++ b/lib/erl_interface/doc/src/registry.xml
@@ -28,18 +28,20 @@
<docno></docno>
<approved>Gordon Beaton</approved>
<checked>Gordon Beaton</checked>
- <date>980707</date>
+ <date>1998-07-07</date>
<rev>A</rev>
<file>registry.xml</file>
</header>
<lib>registry</lib>
- <libsummary>Store and backup key-value pairs.</libsummary>
+ <libsummary>Store and back up key-value pairs.</libsummary>
<description>
<p>This module provides support for storing key-value
pairs in a table known as a registry, backing up registries to
- Mnesia in an atomic manner, and later restoring the contents of a
- registry from Mnesia.</p>
+ <seealso marker="mnesia"><c>Mnesia</c></seealso>
+ in an atomic manner, and later restoring the contents of a
+ registry from <c>Mnesia</c>.</p>
</description>
+
<funcs>
<func>
<name><ret>int</ret><nametext>ei_reg_close(reg)</nametext></name>
@@ -49,14 +51,13 @@
</type>
<desc>
<p>A registry that has previously been created with
- <c><![CDATA[ei_reg_open()]]></c> is closed, and all the objects it contains
- are freed.
- </p>
- <p><c><![CDATA[reg]]></c> is the registry to close.
- </p>
- <p>The function returns 0.</p>
+ <c><![CDATA[ei_reg_open()]]></c> is closed, and all the objects it
+ contains are freed.</p>
+ <p><c><![CDATA[reg]]></c> is the registry to close.</p>
+ <p>Returns <c>0</c>.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_reg_delete(reg,key)</nametext></name>
<fsummary>Delete an object from the registry.</fsummary>
@@ -65,27 +66,28 @@
<v>const char *key;</v>
</type>
<desc>
- <p>Delete an object from the registry. The object is not
- actually removed from the registry, it is only marked for later
- removal so that on subsequent backups to Mnesia, the
- corresponding object can be removed from the Mnesia table as
+ <p>Deletes an object from the registry. The object is not
+ removed from the registry, it is only marked for later
+ removal so that on later backups to <c>Mnesia</c>, the
+ corresponding object can be removed from the <c>Mnesia</c> table as
well. If another object is later created with the same key, the
- object will be reused.
- </p>
- <p>The object will be removed from the registry after a call to
+ object will be reused. </p>
+ <p>The object is removed from the registry after a call to
<c><![CDATA[ei_reg_dump()]]></c> or <c><![CDATA[ei_reg_purge()]]></c>.
- </p>
- <p><c><![CDATA[reg]]></c> is the registry containing <c><![CDATA[key]]></c>.
- </p>
- <p><c><![CDATA[key]]></c> is the object to remove.
- </p>
- <p>If the object was found, the function returns 0 indicating
- success. Otherwise the function returns -1.</p>
+ </p>
+ <list type="bulleted">
+ <item><c><![CDATA[reg]]></c> is the registry containing
+ <c><![CDATA[key]]></c>.</item>
+ <item><c><![CDATA[key]]></c> is the object to remove.</item>
+ </list>
+ <p>Returns <c>0</c> on success, otherwise <c>-1</c>.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_reg_dump(fd,reg,mntab,flags)</nametext></name>
<fsummary>Back up a registry to Mnesia.</fsummary>
+ <marker id="ei_reg_dump"/>
<type>
<v>int fd;</v>
<v>ei_reg *reg;</v>
@@ -93,38 +95,36 @@
<v>int flags;</v>
</type>
<desc>
- <p>Dump the contents of a registry to a Mnesia table in an
- atomic manner, i.e. either all data will be updated, or none of
- it will. If any errors are encountered while backing up
- the data, the entire operation is aborted.
- </p>
- <p><c><![CDATA[fd]]></c> is an open connection to Erlang.
- Mnesia 3.0 or later must be running on the Erlang node.
- </p>
- <p><c><![CDATA[reg]]></c> is the registry to back up.
- </p>
- <p><c><![CDATA[mntab]]></c> is the name of the Mnesia table where the backed
- up data should be placed. If the table does not exist, it will
- be created automatically using configurable defaults. See your
- Mnesia documentation for information about configuring this
- behaviour.
- </p>
- <p>If <c><![CDATA[flags]]></c> is 0, the backup will include only those
- objects which have been created, modified or deleted since the
- last backup or restore (i.e. an incremental backup). After the
+ <p>Dumps the contents of a registry to a <c>Mnesia</c> table in an
+ atomic manner, that is, either all data or no data is updated.
+ If any errors are encountered while backing up
+ the data, the entire operation is aborted.</p>
+ <list type="bulleted">
+ <item><c><![CDATA[fd]]></c> is an open connection to Erlang.
+ <c>Mnesia</c> 3.0 or later must be running on the Erlang node.
+ </item>
+ <item><c><![CDATA[reg]]></c> is the registry to back up.</item>
+ <item><c><![CDATA[mntab]]></c> is the name of the <c>Mnesia</c> table
+ where the backed up data is to be placed. If the table does not
+ exist, it is created automatically using configurable defaults.
+ For information about configuring this behavior, see
+ <seealso marker="mnesia"><c>Mnesia</c></seealso>.</item>
+ </list>
+ <p>If <c><![CDATA[flags]]></c> is <c>0</c>, the backup includes only
+ those objects that have been created, modified, or deleted since the
+ last backup or restore (that is, an incremental backup). After the
backup, any objects that were marked dirty are now clean, and any
- objects that had been marked for deletion are deleted.
- </p>
- <p>Alternatively, setting flags to EI_FORCE will cause a full
- backup to be done, and EI_NOPURGE will cause the deleted objects
- to be left in the registry afterwards. These can be bitwise ORed
- together if both behaviours are desired. If EI_NOPURGE was
- specified, you can use <c><![CDATA[ei_reg_purge()]]></c> to explicitly remove
- the deleted items from the registry later.
- </p>
- <p>The function returns 0 on success, or -1 on failure.</p>
+ objects that had been marked for deletion are deleted.</p>
+ <p>Alternatively, setting flags to <c>EI_FORCE</c> causes a full
+ backup to be done, and <c>EI_NOPURGE</c> causes the deleted objects
+ to be left in the registry afterwards. These can be bitwise OR'ed
+ together if both behaviors are desired. If <c>EI_NOPURGE</c> was
+ specified, <c><![CDATA[ei_reg_purge()]]></c> can be used to
+ explicitly remove the deleted items from the registry later.</p>
+ <p>Returns <c>0</c> on success, otherwise <c>-1</c>.</p>
</desc>
</func>
+
<func>
<name><ret>double</ret><nametext>ei_reg_getfval(reg,key)</nametext></name>
<fsummary>Get a floating point object.</fsummary>
@@ -133,22 +133,24 @@
<v>const char *key;</v>
</type>
<desc>
- <p>Get the value associated with <c><![CDATA[key]]></c> in the
- registry. The value must be a floating point type.
- </p>
- <p><c><![CDATA[reg]]></c> is the registry where the object will be looked
- up.
- </p>
- <p><c><![CDATA[key]]></c> is the name of the object to look up.
- </p>
- <p>On success, the function returns the value associated with <c><![CDATA[key]]></c>.
- If the object was not found or it was not a floating point
- object, -1.0 is returned. To avoid problems with in-band error
- reporting (i.e. if you cannot distinguish between -1.0 and a
- valid result) use the more general function <c><![CDATA[ei_reg_getval()]]></c>
- instead.</p>
+ <p>Gets the value associated with <c><![CDATA[key]]></c> in the
+ registry. The value must be a floating point type.</p>
+ <list type="bulleted">
+ <item><c><![CDATA[reg]]></c> is the registry where the object will be
+ looked up.</item>
+ <item><c><![CDATA[key]]></c> is the name of the object to look up.
+ </item>
+ </list>
+ <p>On success, the function returns the value associated with
+ <c><![CDATA[key]]></c>.
+ If the object is not found or if it is not a floating point
+ object, <c>-1.0</c> is returned. To avoid problems with in-band error
+ reporting (that is, if you cannot distinguish between <c>-1.0</c> and
+ a valid result), use the more general function
+ <c><![CDATA[ei_reg_getval()]]></c> instead.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_reg_getival(reg,key)</nametext></name>
<fsummary>Get an integer object.</fsummary>
@@ -157,22 +159,24 @@
<v>const char *key;</v>
</type>
<desc>
- <p>Get the value associated with <c><![CDATA[key]]></c> in the
- registry. The value must be an integer.
- </p>
- <p><c><![CDATA[reg]]></c> is the registry where the object will be looked
- up.
- </p>
- <p><c><![CDATA[key]]></c> is the name of the object to look up.
- </p>
- <p>On success, the function returns the value associated with <c><![CDATA[key]]></c>.
- If the object was not found or it was not an integer
- object, -1 is returned. To avoid problems with in-band error
- reporting (i.e. if you cannot distinguish between -1 and a
- valid result) use the more general function <c><![CDATA[ei_reg_getval()]]></c>
- instead.</p>
+ <p>Gets the value associated with <c><![CDATA[key]]></c> in the
+ registry. The value must be an integer.</p>
+ <list type="bulleted">
+ <item><c><![CDATA[reg]]></c> is the registry where the object will be
+ looked up.</item>
+ <item><c><![CDATA[key]]></c> is the name of the object to look up.
+ </item>
+ </list>
+ <p>On success, the function returns the value associated with
+ <c><![CDATA[key]]></c>.
+ If the object is not found or if it is not an integer
+ object, <c>-1</c> is returned. To avoid problems with in-band error
+ reporting (that is, if you cannot distinguish between <c>-1</c> and a
+ valid result), use the more general function
+ <c><![CDATA[ei_reg_getval()]]></c> instead.</p>
</desc>
</func>
+
<func>
<name><ret>const void *</ret><nametext>ei_reg_getpval(reg,key,size)</nametext></name>
<fsummary>Get a binary object.</fsummary>
@@ -182,26 +186,27 @@
<v>int size;</v>
</type>
<desc>
- <p>Get the value associated with <c><![CDATA[key]]></c> in the
- registry. The value must be a binary (pointer) type.
- </p>
- <p><c><![CDATA[reg]]></c> is the registry where the object will be looked
- up.
- </p>
- <p><c><![CDATA[key]]></c> is the name of the object to look up.
- </p>
- <p><c><![CDATA[size]]></c> will be initialized to contain the length in
- bytes of the object, if it is found.
- </p>
+ <p>Gets the value associated with <c><![CDATA[key]]></c> in the
+ registry. The value must be a binary (pointer) type.</p>
+ <list type="bulleted">
+ <item><c><![CDATA[reg]]></c> is the registry where the object will be
+ looked up.</item>
+ <item><c><![CDATA[key]]></c> is the name of the object to look up.
+ </item>
+ <item><c><![CDATA[size]]></c> is initialized to contain the length in
+ bytes of the object, if it is found.</item>
+ </list>
<p>On success, the function returns the value associated with
- <c><![CDATA[key]]></c> and indicates its length in <c><![CDATA[size]]></c>.
- If the object was not found or it was not a binary object,
- NULL is returned. To avoid problems with in-band error
- reporting (i.e. if you cannot distinguish between NULL and a
- valid result) use the more general function <c><![CDATA[ei_reg_getval()]]></c>
- instead.</p>
+ <c><![CDATA[key]]></c> and indicates its length in
+ <c><![CDATA[size]]></c>.
+ If the object is not found or if it is not a binary object,
+ <c>NULL</c> is returned. To avoid problems with in-band error
+ reporting (that is, if you cannot distinguish between <c>NULL</c> and
+ a valid result), use the more general function
+ <c><![CDATA[ei_reg_getval()]]></c> instead.</p>
</desc>
</func>
+
<func>
<name><ret>const char *</ret><nametext>ei_reg_getsval(reg,key)</nametext></name>
<fsummary>Get a string object.</fsummary>
@@ -210,22 +215,23 @@
<v>const char *key;</v>
</type>
<desc>
- <p>Get the value associated with <c><![CDATA[key]]></c> in the
- registry. The value must be a string.
- </p>
- <p><c><![CDATA[reg]]></c> is the registry where the object will be looked
- up.
- </p>
- <p><c><![CDATA[key]]></c> is the name of the object to look up.
- </p>
+ <p>Gets the value associated with <c><![CDATA[key]]></c> in the
+ registry. The value must be a string.</p>
+ <list type="bulleted">
+ <item><c><![CDATA[reg]]></c> is the registry where the object will be
+ looked up.</item>
+ <item><c><![CDATA[key]]></c> is the name of the object to look up.
+ </item>
+ </list>
<p>On success, the function returns the value associated with
- <c><![CDATA[key]]></c>. If the object was not found or it was not a string,
- NULL is returned. To avoid problems with in-band error
- reporting (i.e. if you cannot distinguish between NULL and a
- valid result) use the more general function <c><![CDATA[ei_reg_getval()]]></c>
- instead.</p>
+ <c><![CDATA[key]]></c>. If the object is not found or if it is not a
+ string, <c>NULL</c> is returned. To avoid problems with in-band error
+ reporting (that is, if you cannot distinguish between <c>NULL</c> and
+ a valid result), use the more general function
+ <c><![CDATA[ei_reg_getval()]]></c> instead.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_reg_getval(reg,key,flags,v,...)</nametext></name>
<fsummary>Get any object.</fsummary>
@@ -236,56 +242,70 @@
<v>void *v (see below)</v>
</type>
<desc>
- <p>This is a general function for retrieving any kind of
- object from the registry.
- </p>
- <p><c><![CDATA[reg]]></c> is the registry where the object will be looked
- up.
- </p>
- <p><c><![CDATA[key]]></c> is the name of the object to look up.
- </p>
- <p><c><![CDATA[flags]]></c> indicates the type of object that you are
- looking for. If <c><![CDATA[flags]]></c> is 0, then any kind of object will
- be returned. If <c><![CDATA[flags]]></c> is one of EI_INT, EI_FLT, EI_STR or
- EI_BIN, then only values of that kind will be returned. The
- buffer pointed to by <c><![CDATA[v]]></c> must be large enough to hold the return
- data, i.e. it must be a pointer to one of <c><![CDATA[int]]></c>,
- <c><![CDATA[double]]></c>, <c><![CDATA[char*]]></c> or <c><![CDATA[void*]]></c>, respectively. Also,
- if <c><![CDATA[flags]]></c> is EI_BIN, then a fifth argument <c><![CDATA[int *size]]></c> is required, so that the size of the object can be
- returned.
- </p>
- <p>If the function succeeds, <c><![CDATA[v]]></c> (and <c><![CDATA[size]]></c> if the
- object is binary) will be initialized with the value associated
- with <c><![CDATA[key]]></c>, and the function will return one of EI_INT,
- EI_FLT, EI_STR or EI_BIN, indicating the type of object. On failure the
- function will return -1 and the arguments will not be updated.</p>
+ <p>A general function for retrieving any kind of
+ object from the registry.</p>
+ <list type="bulleted">
+ <item>
+ <p><c><![CDATA[reg]]></c> is the registry where the object will be
+ looked up.</p>
+ </item>
+ <item>
+ <p><c><![CDATA[key]]></c> is the name of the object to look up.</p>
+ </item>
+ <item>
+ <p><c><![CDATA[flags]]></c> indicates the type of object that you
+ are looking for. If <c><![CDATA[flags]]></c> is <c>0</c>, any
+ kind of object is returned.
+ If <c><![CDATA[flags]]></c> is <c>EI_INT</c>, <c>EI_FLT</c>,
+ <c>EI_STR</c>, or <c>EI_BIN</c>, then only values of
+ that kind are returned.</p>
+ <p>The buffer pointed to by <c><![CDATA[v]]></c>
+ must be large enough to hold the return data, that is, it must be
+ a pointer to one of <c><![CDATA[int]]></c>,
+ <c><![CDATA[double]]></c>, <c><![CDATA[char*]]></c>, or
+ <c><![CDATA[void*]]></c>, respectively.</p>
+ <p>If <c><![CDATA[flags]]></c> is <c>EI_BIN</c>, a fifth argument
+ <c><![CDATA[int *size]]></c> is required, so that the size of the
+ object can be returned.</p>
+ </item>
+ </list>
+ <p>On success, <c><![CDATA[v]]></c> (and <c><![CDATA[size]]></c> if the
+ object is binary) is initialized with the value associated
+ with <c><![CDATA[key]]></c>, and the function returns <c>EI_INT</c>,
+ <c>EI_FLT</c>, <c>EI_STR</c>, or <c>EI_BIN</c>, indicating the type
+ of object. On failure, <c>-1</c> is returned and the
+ arguments are not updated.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_reg_markdirty(reg,key)</nametext></name>
<fsummary>Mark an object as dirty.</fsummary>
+ <marker id="ei_reg_markdirty"/>
<type>
<v>ei_reg *reg;</v>
<v>const char *key;</v>
</type>
<desc>
- <p>Mark a registry object as dirty. This will ensure that
- it is included in the next backup to Mnesia. Normally this
- operation will not be necessary since all of the normal registry
- 'set' functions do this automatically. However if you have
+ <p>Marks a registry object as dirty. This ensures that
+ it is included in the next backup to <c>Mnesia</c>. Normally this
+ operation is not necessary, as all of the normal registry
+ 'set' functions do this automatically. However, if you have
retrieved the value of a string or binary object from the
- registry and modified the contents, then the change will be
- invisible to the registry and the object will be assumed to be
+ registry and modified the contents, then the change is
+ invisible to the registry and the object is assumed to be
unmodified. This function allows you to make such modifications
- and then let the registry know about them.
- </p>
- <p><c><![CDATA[reg]]></c> is the registry containing the object.
- </p>
- <p><c><![CDATA[key]]></c> is the name of the object to mark.
- </p>
- <p>The function returns 0 on success, or -1 on failure.</p>
+ and then let the registry know about them.</p>
+ <list type="bulleted">
+ <item><c><![CDATA[reg]]></c> is the registry containing the object.
+ </item>
+ <item><c><![CDATA[key]]></c> is the name of the object to mark.
+ </item>
+ </list>
+ <p>Returns <c>0</c> on success, otherwise <c>-1</c>.</p>
</desc>
</func>
+
<func>
<name><ret>ei_reg *</ret><nametext>ei_reg_open(size)</nametext></name>
<fsummary>Create and open a registry.</fsummary>
@@ -293,24 +313,20 @@
<v>int size;</v>
</type>
<desc>
- <p>Open (create) a registry. The registry will be
- initially empty. Use <c><![CDATA[ei_reg_close()]]></c> to close the registry
- later.
- </p>
- <p><c><![CDATA[size]]></c> is the approximate number of objects you intend
- to store in the registry. Since the registry uses a hash table
- with collision chaining, there is no absolute upper limit on the
- number of objects that can be stored in it. However for reasons
+ <p>Opens (creates) a registry, which initially is empty. To
+ close the registry later, use <c><![CDATA[ei_reg_close()]]></c>.</p>
+ <p><c><![CDATA[size]]></c> is the approximate number of objects you
+ intend to store in the registry. As the registry uses a hash table
+ with collision chaining, no absolute upper limit exists on the
+ number of objects that can be stored in it. However, for reasons
of efficiency, it is a good idea to choose a number that is
- appropriate for your needs. It is possible to use
- <c><![CDATA[ei_reg_resize()]]></c> to change the size later. Note that the
- number you provide will be increased to the nearest larger prime
- number.
- </p>
- <p>On success, an empty registry will be returned. On failure, NULL
- will be returned.</p>
+ appropriate for your needs. To change the size later, use
+ <c><![CDATA[ei_reg_resize()]]></c>. Notice that the number
+ you provide is increased to the nearest larger prime number.</p>
+ <p>Returns an empty registry on success, otherwise <c>NULL</c>.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_reg_purge(reg)</nametext></name>
<fsummary>Remove deleted objects.</fsummary>
@@ -318,20 +334,19 @@
<v>ei_reg *reg;</v>
</type>
<desc>
- <p>Remove all objects marked for deletion. When objects
- are deleted with <c><![CDATA[ei_reg_delete()]]></c> they are not actually
- removed from the registry, only marked for later removal. This
- is so that on a subsequent backup to Mnesia, the
- objects can also be removed from the Mnesia table. If you are
- not backing up to Mnesia then you may wish to remove the objects
- manually with this function.
- </p>
+ <p>Removes all objects marked for deletion. When objects
+ are deleted with <c><![CDATA[ei_reg_delete()]]></c> they are not
+ removed from the registry, only marked for later removal.
+ On a later backup to <c>Mnesia</c>, the
+ objects can also be removed from the <c>Mnesia</c> table. If you are
+ not backing up to <c>Mnesia</c>, you may wish to remove the objects
+ manually with this function.</p>
<p><c><![CDATA[reg]]></c> is a registry containing objects marked for
- deletion.
- </p>
- <p>The function returns 0 on success, or -1 on failure.</p>
+ deletion.</p>
+ <p>Returns <c>0</c> on success, otherwise <c>-1</c>.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_reg_resize(reg,newsize)</nametext></name>
<fsummary>Resize a registry.</fsummary>
@@ -340,16 +355,15 @@
<v>int newsize;</v>
</type>
<desc>
- <p>Change the size of a registry.
- </p>
+ <p>Changes the size of a registry.</p>
<p><c><![CDATA[newsize]]></c> is the new size to make the registry. The
- number will be increased to the nearest larger prime number.
- </p>
- <p>On success, the registry will be resized, all contents
- rehashed, and the function will return 0. On failure, the
- registry will be left unchanged and the function will return -1.</p>
+ number is increased to the nearest larger prime number.</p>
+ <p>On success, the registry is resized, all contents
+ rehashed, and <c>0</c> is returned. On failure, the
+ registry is left unchanged and <c>-1</c> is returned.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_reg_restore(fd,reg,mntab)</nametext></name>
<fsummary>Restore a registry from Mnesia.</fsummary>
@@ -359,35 +373,33 @@
<v>const char *mntab;</v>
</type>
<desc>
- <p>The contents of a Mnesia table are read into the
- registry.
- </p>
- <p><c><![CDATA[fd]]></c> is an open connection to Erlang.
- Mnesia 3.0 or later must be running on the Erlang node.
- </p>
- <p><c><![CDATA[reg]]></c> is the registry where the data should be placed.
- </p>
- <p><c><![CDATA[mntab]]></c> is the name of the Mnesia table to read data
- from.
- </p>
- <p>Note that only tables of a certain format can be
- restored, i.e. those that have been created and backed up to
- with <c><![CDATA[ei_reg_dump()]]></c>. If the registry was not empty before
- the operation, then the contents of the table are added to the
+ <p>The contents of a <c>Mnesia</c> table are read into the registry.</p>
+ <list type="bulleted">
+ <item><c><![CDATA[fd]]></c> is an open connection to Erlang.
+ <c>Mnesia</c> 3.0 or later must be running on the Erlang node.
+ </item>
+ <item><c><![CDATA[reg]]></c> is the registry where the data is to be
+ placed.</item>
+ <item><c><![CDATA[mntab]]></c> is the name of the <c>Mnesia</c> table
+ to read data from.</item>
+ </list>
+ <p>Notice that only tables of a certain format can be
+ restored, that is, those that have been created and backed up to
+ with <c><![CDATA[ei_reg_dump()]]></c>. If the registry was not empty
+ before the operation, the contents of the table are added to the
contents of the registry. If the table contains objects with the
same keys as those already in the registry, the registry objects
- will be overwritten with the new values. If the registry
- contains objects that were not in the table, they will be
- unchanged by this operation.
- </p>
+ are overwritten with the new values. If the registry
+ contains objects that were not in the table, they are
+ unchanged by this operation.</p>
<p>After the restore operation, the entire contents of the
- registry is marked as unmodified. Note that this includes any
+ registry is marked as unmodified. Notice that this includes any
objects that were modified before the restore and not
- overwritten by the restore.
- </p>
- <p>The function returns 0 on success, or -1 on failure.</p>
+ overwritten by the restore.</p>
+ <p>Returns <c>0</c> on success, otherwise <c>-1</c>.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_reg_setfval(reg,key,f)</nametext></name>
<fsummary>Assign a floating point object.</fsummary>
@@ -397,20 +409,22 @@
<v>double f;</v>
</type>
<desc>
- <p>Create a key-value pair with the specified <c><![CDATA[key]]></c> and
- floating point value <c><![CDATA[f]]></c>. If an object already existed with
- the same <c><![CDATA[key]]></c>, the new value replaces the old one. If the
- previous value was a binary or string, it is freed with <c><![CDATA[free()]]></c>.
- </p>
- <p><c><![CDATA[reg]]></c> is the registry where the object should be placed.
- </p>
- <p><c><![CDATA[key]]></c> is the name of the object.
- </p>
- <p><c><![CDATA[f]]></c> is the floating point value to assign.
- </p>
- <p>The function returns 0 on success, or -1 on failure.</p>
+ <p>Creates a key-value pair with the specified <c><![CDATA[key]]></c>
+ and floating point value <c><![CDATA[f]]></c>. If an object already
+ exists with the same <c><![CDATA[key]]></c>, the new value replaces
+ the old one. If the previous value was a binary or string, it is
+ freed with <c><![CDATA[free()]]></c>.</p>
+ <list type="bulleted">
+ <item><c><![CDATA[reg]]></c> is the registry where the object is to be
+ placed.</item>
+ <item><c><![CDATA[key]]></c> is the object name.</item>
+ <item><c><![CDATA[f]]></c> is the floating point value to assign.
+ </item>
+ </list>
+ <p>Returns <c>0</c> on success, otherwise <c>-1</c>.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_reg_setival(reg,key,i)</nametext></name>
<fsummary>Assign an integer object.</fsummary>
@@ -420,20 +434,21 @@
<v>int i;</v>
</type>
<desc>
- <p>Create a key-value pair with the specified <c><![CDATA[key]]></c> and integer
- value <c><![CDATA[i]]></c>. If an object already existed with the same
- <c><![CDATA[key]]></c>, the new value replaces the old one. If the previous
- value was a binary or string, it is freed with <c><![CDATA[free()]]></c>.
- </p>
- <p><c><![CDATA[reg]]></c> is the registry where the object should be placed.
- </p>
- <p><c><![CDATA[key]]></c> is the name of the object.
- </p>
- <p><c><![CDATA[i]]></c> is the integer value to assign.
- </p>
- <p>The function returns 0 on success, or -1 on failure.</p>
+ <p>Creates a key-value pair with the specified <c><![CDATA[key]]></c>
+ and integer value <c><![CDATA[i]]></c>. If an object already exists
+ with the same <c><![CDATA[key]]></c>, the new value replaces the old
+ one. If the previous value was a binary or string, it is freed with
+ <c><![CDATA[free()]]></c>.</p>
+ <list type="bulleted">
+ <item><c><![CDATA[reg]]></c> is the registry where the object is to be
+ placed.</item>
+ <item><c><![CDATA[key]]></c> is the object name.</item>
+ <item><c><![CDATA[i]]></c> is the integer value to assign.</item>
+ </list>
+ <p>Returns <c>0</c> on success, otherwise <c>-1</c>.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_reg_setpval(reg,key,p,size)</nametext></name>
<fsummary>Assign a binary object.</fsummary>
@@ -444,26 +459,27 @@
<v>int size;</v>
</type>
<desc>
- <p>Create a key-value pair with the specified <c><![CDATA[key]]></c> whose
- "value" is the binary object pointed to by <c><![CDATA[p]]></c>. If an
- object already existed with the same <c><![CDATA[key]]></c>, the new value
- replaces the old one. If the previous value was a binary or
- string, it is freed with <c><![CDATA[free()]]></c>.
- </p>
- <p><c><![CDATA[reg]]></c> is the registry where the object should be placed.
- </p>
- <p><c><![CDATA[key]]></c> is the name of the object.
- </p>
- <p><c><![CDATA[p]]></c> is a pointer to the binary object. The object itself
- must have been created through a single call to <c><![CDATA[malloc()]]></c> or
- similar function, so that the registry can later delete it if
- necessary by calling <c><![CDATA[free()]]></c>.
- </p>
- <p><c><![CDATA[size]]></c> is the length in bytes of the binary object.
- </p>
- <p>The function returns 0 on success, or -1 on failure.</p>
+ <p>Creates a key-value pair with the specified <c><![CDATA[key]]></c>
+ whose "value" is the binary object pointed to by <c><![CDATA[p]]></c>.
+ If an object already exists with the same <c><![CDATA[key]]></c>,
+ the new value replaces the old one. If the previous value was a
+ binary or string, it is freed with <c><![CDATA[free()]]></c>.</p>
+ <list type="bulleted">
+ <item><c><![CDATA[reg]]></c> is the registry where the object is to be
+ placed.</item>
+ <item><c><![CDATA[key]]></c> is the object name.</item>
+ <item><c><![CDATA[p]]></c> is a pointer to the binary object. The
+ object itself must have been created through a single call to
+ <c><![CDATA[malloc()]]></c> or a similar function, so that the
+ registry can later delete it if necessary by calling
+ <c><![CDATA[free()]]></c>.</item>
+ <item><c><![CDATA[size]]></c> is the length in bytes of the binary
+ object.</item>
+ </list>
+ <p>Returns <c>0</c> on success, otherwise <c>-1</c>.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_reg_setsval(reg,key,s)</nametext></name>
<fsummary>Assign a string object.</fsummary>
@@ -473,24 +489,25 @@
<v>const char *s;</v>
</type>
<desc>
- <p>Create a key-value pair with the specified <c><![CDATA[key]]></c> whose
- "value" is the specified string <c><![CDATA[s]]></c>. If an object already
- existed with the same <c><![CDATA[key]]></c>, the new value replaces the old
- one. If the previous value was a binary or string, it is freed
- with <c><![CDATA[free()]]></c>.
- </p>
- <p><c><![CDATA[reg]]></c> is the registry where the object should be placed.
- </p>
- <p><c><![CDATA[key]]></c> is the name of the object.
- </p>
- <p><c><![CDATA[s]]></c> is the string to assign. The string itself
- must have been created through a single call to <c><![CDATA[malloc()]]></c> or
- similar function, so that the registry can later delete it if
- necessary by calling <c><![CDATA[free()]]></c>.
- </p>
- <p>The function returns 0 on success, or -1 on failure.</p>
+ <p>Creates a key-value pair with the specified <c><![CDATA[key]]></c>
+ whose "value" is the specified string <c><![CDATA[s]]></c>. If an
+ object already exists with the same <c><![CDATA[key]]></c>, the new
+ value replaces the old one. If the previous value was a binary or
+ string, it is freed with <c><![CDATA[free()]]></c>.</p>
+ <list type="bulleted">
+ <item><c><![CDATA[reg]]></c> is the registry where the object is to be
+ placed.</item>
+ <item><c><![CDATA[key]]></c> is the object name.</item>
+ <item><c><![CDATA[s]]></c> is the string to assign. The string itself
+ must have been created through a single call to
+ <c><![CDATA[malloc()]]></c> or similar a function,
+ so that the registry can later delete it if
+ necessary by calling <c><![CDATA[free()]]></c>.</item>
+ </list>
+ <p>Returns <c>0</c> on success, otherwise <c>-1</c>.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_reg_setval(reg,key,flags,v,...)</nametext></name>
<fsummary>Assign a value to any object type.</fsummary>
@@ -501,31 +518,41 @@
<v>v (see below)</v>
</type>
<desc>
- <p>Create a key-value pair with the specified <c><![CDATA[key]]></c> whose
- value is specified by <c><![CDATA[v]]></c>. If an object already
- existed with the same <c><![CDATA[key]]></c>, the new value replaces the old
- one. If the previous value was a binary or string, it is freed
- with <c><![CDATA[free()]]></c>.
- </p>
- <p><c><![CDATA[reg]]></c> is the registry where the object should be placed.
- </p>
- <p><c><![CDATA[key]]></c> is the name of the object.
- </p>
- <p><c><![CDATA[flags]]></c> indicates the type of the object specified by
- <c><![CDATA[v]]></c>. Flags must be one of EI_INT, EI_FLT, EI_STR and
- EI_BIN, indicating whether <c><![CDATA[v]]></c> is <c><![CDATA[int]]></c>, <c><![CDATA[double]]></c>,
- <c><![CDATA[char*]]></c> or <c><![CDATA[void*]]></c>. If <c><![CDATA[flags]]></c> is EI_BIN, then a
- fifth argument <c><![CDATA[size]]></c> is required, indicating the size
- in bytes of the object pointed to by <c><![CDATA[v]]></c>.
- </p>
+ <p>Creates a key-value pair with the specified <c><![CDATA[key]]></c>
+ whose value is specified by <c><![CDATA[v]]></c>. If an object already
+ exists with the same <c><![CDATA[key]]></c>, the new value replaces
+ the old one. If the previous value was a binary or string, it is freed
+ with <c><![CDATA[free()]]></c>.</p>
+ <list type="bulleted">
+ <item>
+ <p><c><![CDATA[reg]]></c> is the registry where the object is to be
+ placed.</p>
+ </item>
+ <item>
+ <p><c><![CDATA[key]]></c> is the object name.</p>
+ </item>
+ <item>
+ <p><c><![CDATA[flags]]></c> indicates the type of the object
+ specified by <c><![CDATA[v]]></c>. Flags must be one of
+ <c>EI_INT</c>, <c>EI_FLT</c>, <c>EI_STR</c>, and <c>EI_BIN</c>,
+ indicating whether
+ <c><![CDATA[v]]></c> is <c><![CDATA[int]]></c>,
+ <c><![CDATA[double]]></c>, <c><![CDATA[char*]]></c>, or
+ <c><![CDATA[void*]]></c>.</p>
+ <p>If <c><![CDATA[flags]]></c> is <c>EI_BIN</c>, a fifth argument
+ <c><![CDATA[size]]></c> is required, indicating the size
+ in bytes of the object pointed to by <c><![CDATA[v]]></c>.</p>
+ </item>
+ </list>
<p>If you wish to store an arbitrary pointer in the registry,
- specify a <c><![CDATA[size]]></c> of 0. In this case, the object itself will
- not be transferred by an <c><![CDATA[ei_reg_dump()]]></c> operation, just
- the pointer value.
- </p>
- <p>The function returns 0 on success, or -1 on failure.</p>
+ specify a <c><![CDATA[size]]></c> of <c>0</c>. In this case, the
+ object itself is not transferred by an
+ <c><![CDATA[ei_reg_dump()]]></c> operation, only the pointer
+ value.</p>
+ <p>Returns <c>0</c> on success, otherwise <c>-1</c>.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_reg_stat(reg,key,obuf)</nametext></name>
<fsummary>Get object information.</fsummary>
@@ -535,34 +562,35 @@
<v>struct ei_reg_stat *obuf;</v>
</type>
<desc>
- <p>Return information about an object.
- </p>
- <p><c><![CDATA[reg]]></c> is the registry containing the object.
- </p>
- <p><c><![CDATA[key]]></c> is the name of the object.
- </p>
- <p><c><![CDATA[obuf]]></c> is a pointer to an <c><![CDATA[ei_reg_stat]]></c> structure,
- defined below:
- </p>
+ <p>Returns information about an object.</p>
+ <list type="bulleted">
+ <item><c><![CDATA[reg]]></c> is the registry containing the object.
+ </item>
+ <item><c><![CDATA[key]]></c> is the object name.</item>
+ <item><c><![CDATA[obuf]]></c> is a pointer to an
+ <c><![CDATA[ei_reg_stat]]></c> structure, defined as follows:</item>
+ </list>
<code type="none"><![CDATA[
struct ei_reg_stat {
int attr;
int size;
};
]]></code>
- <p>In <c><![CDATA[attr]]></c> the object's attributes are stored as the logical
- OR of its type (one of EI_INT, EI_FLT, EI_BIN and EI_STR),
- whether it is marked for deletion (EI_DELET) and whether it has
- been modified since the last backup to Mnesia (EI_DIRTY).
- </p>
- <p>The <c><![CDATA[size]]></c> field indicates the size in bytes required to store
- EI_STR (including the terminating 0) and EI_BIN objects, or 0
- for EI_INT and EI_FLT.
- </p>
- <p>The function returns 0 and initializes <c><![CDATA[obuf]]></c> on
- success, or returns -1 on failure.</p>
+ <p>In <c><![CDATA[attr]]></c> the attributes of the object are stored
+ as the logical <em>OR</em> of its type (one of <c>EI_INT</c>,
+ <c>EI_FLT</c>, <c>EI_BIN</c>, and <c>EI_STR</c>),
+ whether it is marked for deletion (<c>EI_DELET</c>), and whether it
+ has been modified since the last backup to <c>Mnesia</c>
+ (<c>EI_DIRTY</c>).</p>
+ <p>Field <c><![CDATA[size]]></c> indicates the size in bytes required
+ to store <c>EI_STR</c> (including the terminating <c>0</c>) and
+ <c>EI_BIN</c> objects, or <c>0</c> for <c>EI_INT</c> and
+ <c>EI_FLT</c>.</p>
+ <p>Returns <c>0</c> and initializes <c><![CDATA[obuf]]></c> on success,
+ otherwise <c>-1</c>.</p>
</desc>
</func>
+
<func>
<name><ret>int</ret><nametext>ei_reg_tabstat(reg,obuf)</nametext></name>
<fsummary>Get registry information.</fsummary>
@@ -571,15 +599,16 @@ struct ei_reg_stat {
<v>struct ei_reg_tabstat *obuf;</v>
</type>
<desc>
- <p>Return information about a registry. Using information
+ <p>Returns information about a registry. Using information
returned by this function, you can see whether the size of the
- registry is suitable for the amount of data it contains.
- </p>
- <p><c><![CDATA[reg]]></c> is the registry to return information about.
- </p>
- <p><c><![CDATA[obuf]]></c> is a pointer to an <c><![CDATA[ei_reg_tabstat]]></c> structure,
- defined below:
- </p>
+ registry is suitable for the amount of data it contains.</p>
+ <list type="bulleted">
+ <item><c><![CDATA[reg]]></c> is the registry to return information
+ about.</item>
+ <item><c><![CDATA[obuf]]></c> is a pointer to an
+ <c><![CDATA[ei_reg_tabstat]]></c> structure, defined as follows:
+ </item>
+ </list>
<code type="none"><![CDATA[
struct ei_reg_tabstat {
int size;
@@ -588,23 +617,22 @@ struct ei_reg_tabstat {
int collisions;
};
]]></code>
- <p>The <c><![CDATA[size]]></c> field indicates the number of hash positions
+ <p>Field <c><![CDATA[size]]></c> indicates the number of hash positions
in the registry. This is the number you provided when you
created or last resized the registry, rounded up to the nearest
- prime.
- </p>
- <p><c><![CDATA[nelem]]></c> indicates the number of elements stored in the
- registry. It includes objects that are deleted but not purged.
- </p>
- <p><c><![CDATA[npos]]></c> indicates the number of unique positions that are
- occupied in the registry.
- </p>
- <p><c><![CDATA[collisions]]></c> indicates how many elements are sharing
- positions in the registry.
- </p>
- <p>On success, the function returns 0 and <c><![CDATA[obuf]]></c> is
- initialized to contain table statistics. On failure, the function
- returns -1.</p>
+ prime number.</p>
+ <list type="bulleted">
+ <item><c><![CDATA[nelem]]></c> indicates the number of elements stored
+ in the registry. It includes objects that are deleted but not
+ purged.</item>
+ <item><c><![CDATA[npos]]></c> indicates the number of unique positions
+ that are occupied in the registry.</item>
+ <item><c><![CDATA[collisions]]></c> indicates how many elements are
+ sharing positions in the registry.</item>
+ </list>
+ <p>On success, <c>0</c> is returned and
+ <c><![CDATA[obuf]]></c> is initialized to contain table statistics,
+ otherwise <c>-1</c> is returned.</p>
</desc>
</func>
</funcs>