aboutsummaryrefslogtreecommitdiffstats
path: root/lib/stdlib/doc/src/beam_lib.xml
diff options
context:
space:
mode:
Diffstat (limited to 'lib/stdlib/doc/src/beam_lib.xml')
-rw-r--r--lib/stdlib/doc/src/beam_lib.xml528
1 files changed, 288 insertions, 240 deletions
diff --git a/lib/stdlib/doc/src/beam_lib.xml b/lib/stdlib/doc/src/beam_lib.xml
index 7c89c8b43e..d5ec90b060 100644
--- a/lib/stdlib/doc/src/beam_lib.xml
+++ b/lib/stdlib/doc/src/beam_lib.xml
@@ -4,7 +4,7 @@
<erlref>
<header>
<copyright>
- <year>2000</year><year>2015</year>
+ <year>2000</year><year>2016</year>
<holder>Ericsson AB. All Rights Reserved.</holder>
</copyright>
<legalnotice>
@@ -29,137 +29,159 @@
<rev>PA1</rev>
</header>
<module>beam_lib</module>
- <modulesummary>An Interface To the BEAM File Format</modulesummary>
+ <modulesummary>An interface to the BEAM file format.</modulesummary>
<description>
- <p><c>beam_lib</c> provides an interface to files created by
- the BEAM compiler ("BEAM files"). The format used, a variant of
+ <p>This module provides an interface to files created by
+ the BEAM Compiler ("BEAM files"). The format used, a variant of
"EA IFF 1985" Standard for Interchange Format Files, divides data
into chunks.</p>
+
<p>Chunk data can be returned as binaries or as compound terms.
Compound terms are returned when chunks are referenced by names
- (atoms) rather than identifiers (strings). The names recognized
- and the corresponding identifiers are:</p>
+ (atoms) rather than identifiers (strings). The recognized names
+ and the corresponding identifiers are as follows:</p>
+
<list type="bulleted">
<item><c>abstract_code ("Abst")</c></item>
+ <item><c>atoms ("Atom")</c></item>
<item><c>attributes ("Attr")</c></item>
<item><c>compile_info ("CInf")</c></item>
<item><c>exports ("ExpT")</c></item>
- <item><c>labeled_exports ("ExpT")</c></item>
<item><c>imports ("ImpT")</c></item>
<item><c>indexed_imports ("ImpT")</c></item>
- <item><c>locals ("LocT")</c></item>
+ <item><c>labeled_exports ("ExpT")</c></item>
<item><c>labeled_locals ("LocT")</c></item>
- <item><c>atoms ("Atom")</c></item>
+ <item><c>locals ("LocT")</c></item>
</list>
</description>
<section>
<marker id="debug_info"></marker>
<title>Debug Information/Abstract Code</title>
- <p>The option <c>debug_info</c> can be given to the compiler (see
- <seealso marker="compiler:compile#debug_info">compile(3)</seealso>)
- in order to have debug information in the form of abstract code
- (see <seealso marker="erts:absform">The Abstract Format</seealso>
- in ERTS User's Guide) stored in the <c>abstract_code</c> chunk.
+ <p>Option <c>debug_info</c> can be specified to the Compiler (see
+ <seealso marker="compiler:compile#debug_info"><c>compile(3)</c></seealso>)
+ to have debug information in the form of abstract code (see section
+ <seealso marker="erts:absform">The Abstract Format</seealso> in the
+ ERTS User's Guide) stored in the <c>abstract_code</c> chunk.
Tools such as Debugger and Xref require the debug information to
be included.</p>
+
<warning>
<p>Source code can be reconstructed from the debug information.
- Use encrypted debug information (see below) to prevent this.</p>
+ To prevent this, use encrypted debug information (see below).</p>
</warning>
+
<p>The debug information can also be removed from BEAM files
- using <seealso marker="#strip/1">strip/1</seealso>,
- <seealso marker="#strip_files/1">strip_files/1</seealso> and/or
- <seealso marker="#strip_release/1">strip_release/1</seealso>.</p>
+ using <seealso marker="#strip/1"><c>strip/1</c></seealso>,
+ <seealso marker="#strip_files/1"><c>strip_files/1</c></seealso>, and/or
+ <seealso marker="#strip_release/1"><c>strip_release/1</c></seealso>.</p>
</section>
- <section>
- <title>Reconstructing source code</title>
- <p>Here is an example of how to reconstruct source code from
- the debug information in a BEAM file <c>Beam</c>:</p>
- <code type="none">
- {ok,{_,[{abstract_code,{_,AC}}]}} = beam_lib:chunks(Beam,[abstract_code]).
- io:fwrite("~s~n", [erl_prettypr:format(erl_syntax:form_list(AC))]).</code>
- </section>
- <section>
- <title>Encrypted debug information</title>
- <p>The debug information can be encrypted in order to keep
- the source code secret, but still being able to use tools such as
- Xref or Debugger. </p>
- <p>To use encrypted debug information, a key must be provided to
- the compiler and <c>beam_lib</c>. The key is given as a string and
- it is recommended that it contains at least 32 characters and
- that both upper and lower case letters as well as digits and
- special characters are used.</p>
- <p>The default type -- and currently the only type -- of crypto
- algorithm is <c>des3_cbc</c>, three rounds of DES. The key string
- will be scrambled using <c>erlang:md5/1</c> to generate
- the actual keys used for <c>des3_cbc</c>.</p>
- <note>
- <p>As far as we know by the time of writing, it is
- infeasible to break <c>des3_cbc</c> encryption without any
- knowledge of the key. Therefore, as long as the key is kept
- safe and is unguessable, the encrypted debug information
- <em>should</em> be safe from intruders.</p>
- </note>
- <p>There are two ways to provide the key:</p>
- <list type="ordered">
- <item>
- <p>Use the compiler option <c>{debug_info,Key}</c>, see
- <seealso marker="compiler:compile#debug_info_key">compile(3)</seealso>,
- and the function
- <seealso marker="#crypto_key_fun/1">crypto_key_fun/1</seealso>
- to register a fun which returns the key whenever
- <c>beam_lib</c> needs to decrypt the debug information.</p>
- <p>If no such fun is registered, <c>beam_lib</c> will instead
- search for a <c>.erlang.crypt</c> file, see below.</p>
- </item>
- <item>
- <p>Store the key in a text file named <c>.erlang.crypt</c>.</p>
- <p>In this case, the compiler option <c>encrypt_debug_info</c>
- can be used, see
- <seealso marker="compiler:compile#encrypt_debug_info">compile(3)</seealso>.</p>
- </item>
- </list>
+
+ <section>
+ <title>Reconstruct Source Code</title>
+ <p>The following example shows how to reconstruct source code from
+ the debug information in a BEAM file <c>Beam</c>:</p>
+
+ <code type="none">
+{ok,{_,[{abstract_code,{_,AC}}]}} = beam_lib:chunks(Beam,[abstract_code]).
+io:fwrite("~s~n", [erl_prettypr:format(erl_syntax:form_list(AC))]).</code>
</section>
- <section>
- <title>.erlang.crypt</title>
- <p><c>beam_lib</c> searches for <c>.erlang.crypt</c> in the current
- directory and then the home directory for the current user. If
- the file is found and contains a key, <c>beam_lib</c> will
- implicitly create a crypto key fun and register it.</p>
- <p>The <c>.erlang.crypt</c> file should contain a single list of
- tuples:</p>
- <code type="none">
- {debug_info, Mode, Module, Key}</code>
- <p><c>Mode</c> is the type of crypto algorithm; currently, the only
- allowed value thus is <c>des3_cbc</c>. <c>Module</c> is either an
- atom, in which case <c>Key</c> will only be used for the module
- <c>Module</c>, or <c>[]</c>, in which case <c>Key</c> will be
- used for all modules. <c>Key</c> is the non-empty key string.</p>
- <p>The <c>Key</c> in the first tuple where both <c>Mode</c> and
- <c>Module</c> matches will be used.</p>
- <p>Here is an example of an <c>.erlang.crypt</c> file that returns
- the same key for all modules:</p>
- <code type="none"><![CDATA[
+
+ <section>
+ <title>Encrypted Debug Information</title>
+ <p>The debug information can be encrypted to keep
+ the source code secret, but still be able to use tools such as
+ Debugger or Xref.</p>
+
+ <p>To use encrypted debug information, a key must be provided to
+ the compiler and <c>beam_lib</c>. The key is specified as a string.
+ It is recommended that the string contains at least 32 characters and
+ that both upper and lower case letters as well as digits and
+ special characters are used.</p>
+
+ <p>The default type (and currently the only type) of crypto
+ algorithm is <c>des3_cbc</c>, three rounds of DES. The key string
+ is scrambled using
+ <seealso marker="erts:erlang#md5/1"><c>erlang:md5/1</c></seealso>
+ to generate the keys used for <c>des3_cbc</c>.</p>
+
+ <note>
+ <p>As far as we know by the time of writing, it is
+ infeasible to break <c>des3_cbc</c> encryption without any
+ knowledge of the key. Therefore, as long as the key is kept
+ safe and is unguessable, the encrypted debug information
+ <em>should</em> be safe from intruders.</p>
+ </note>
+
+ <p>The key can be provided in the following two ways:</p>
+
+ <list type="ordered">
+ <item>
+ <p>Use Compiler option <c>{debug_info,Key}</c>, see
+ <seealso marker="compiler:compile#debug_info_key"><c>compile(3)</c></seealso>
+ and function
+ <seealso marker="#crypto_key_fun/1"><c>crypto_key_fun/1</c></seealso>
+ to register a fun that returns the key whenever
+ <c>beam_lib</c> must decrypt the debug information.</p>
+ <p>If no such fun is registered, <c>beam_lib</c> instead
+ searches for an <c>.erlang.crypt</c> file, see the next section.</p>
+ </item>
+ <item>
+ <p>Store the key in a text file named <c>.erlang.crypt</c>.</p>
+ <p>In this case, Compiler option <c>encrypt_debug_info</c>
+ can be used, see
+ <seealso marker="compiler:compile#encrypt_debug_info"><c>compile(3)</c></seealso>.
+ </p>
+ </item>
+ </list>
+ </section>
+
+ <section>
+ <title>.erlang.crypt</title>
+ <p><c>beam_lib</c> searches for <c>.erlang.crypt</c> in the current
+ directory and then the home directory for the current user. If
+ the file is found and contains a key, <c>beam_lib</c>
+ implicitly creates a crypto key fun and registers it.</p>
+
+ <p>File <c>.erlang.crypt</c> is to contain a single list of tuples:</p>
+
+ <code type="none">
+{debug_info, Mode, Module, Key}</code>
+
+ <p><c>Mode</c> is the type of crypto algorithm; currently, the only
+ allowed value is <c>des3_cbc</c>. <c>Module</c> is either an
+ atom, in which case <c>Key</c> is only used for the module
+ <c>Module</c>, or <c>[]</c>, in which case <c>Key</c> is
+ used for all modules. <c>Key</c> is the non-empty key string.</p>
+
+ <p><c>Key</c> in the first tuple where both <c>Mode</c> and
+ <c>Module</c> match is used.</p>
+
+ <p>The following is an example of an <c>.erlang.crypt</c> file that returns
+ the same key for all modules:</p>
+
+ <code type="none"><![CDATA[
[{debug_info, des3_cbc, [], "%>7}|pc/DM6Cga*68$Mw]L#&_Gejr]G^"}].]]></code>
- <p>And here is a slightly more complicated example of an
- <c>.erlang.crypt</c> which provides one key for the module
- <c>t</c>, and another key for all other modules:</p>
- <code type="none"><![CDATA[
+
+ <p>The following is a slightly more complicated example of an
+ <c>.erlang.crypt</c> providing one key for module
+ <c>t</c> and another key for all other modules:</p>
+
+ <code type="none"><![CDATA[
[{debug_info, des3_cbc, t, "My KEY"},
{debug_info, des3_cbc, [], "%>7}|pc/DM6Cga*68$Mw]L#&_Gejr]G^"}].]]></code>
- <note>
- <p>Do not use any of the keys in these examples. Use your own
- keys.</p>
- </note>
- </section>
+
+ <note>
+ <p>Do not use any of the keys in these examples. Use your own keys.</p>
+ </note>
+ </section>
<datatypes>
<datatype>
<name name="beam"/>
<desc>
<p>Each of the functions described below accept either the
- module name, the filename, or a binary containing the beam
+ module name, the filename, or a binary containing the BEAM
module.</p>
</desc>
</datatype>
@@ -167,7 +189,7 @@
<name name="chunkdata"/>
<desc>
<p>The list of attributes is sorted on <c>Attribute</c>
- (in attrib_entry()), and each
+ (in <c>attrib_entry()</c>) and each
attribute name occurs once in the list. The attribute values
occur in the same order as in the file. The lists of functions
are also sorted.</p>
@@ -186,8 +208,8 @@
<name name="abst_code"/>
<desc>
<p>It is not checked that the forms conform to the abstract format
- indicated by <c><anno>AbstVersion</anno></c>. <c>no_abstract_code</c> means
- that the <c>"Abst"</c> chunk is present, but empty.</p>
+ indicated by <c><anno>AbstVersion</anno></c>. <c>no_abstract_code</c>
+ means that chunk <c>"Abst"</c> is present, but empty.</p>
</desc>
</datatype>
<datatype>
@@ -230,78 +252,163 @@
<p>Reads chunk data for all chunks.</p>
</desc>
</func>
+
+ <func>
+ <name name="build_module" arity="1"/>
+ <fsummary>Create a BEAM module from a list of chunks.</fsummary>
+ <desc>
+ <p>Builds a BEAM module (as a binary) from a list of chunks.</p>
+ </desc>
+ </func>
+
<func>
<name name="chunks" arity="2"/>
- <fsummary>Read selected chunks from a BEAM file or binary</fsummary>
+ <fsummary>Read selected chunks from a BEAM file or binary.</fsummary>
<desc>
- <p>Reads chunk data for selected chunks refs. The order of
+ <p>Reads chunk data for selected chunks references. The order of
the returned list of chunk data is determined by the order
of the list of chunks references.</p>
</desc>
</func>
+
<func>
<name name="chunks" arity="3"/>
- <fsummary>Read selected chunks from a BEAM file or binary</fsummary>
+ <fsummary>Read selected chunks from a BEAM file or binary.</fsummary>
<desc>
- <p>Reads chunk data for selected chunks refs. The order of
+ <p>Reads chunk data for selected chunks references. The order of
the returned list of chunk data is determined by the order
of the list of chunks references.</p>
- <p>By default, if any requested chunk is missing in <c><anno>Beam</anno></c>,
- an <c>error</c> tuple is returned.
- However, if the option <c>allow_missing_chunks</c> has been given,
- a result will be returned even if chunks are missing.
- In the result list, any missing chunks will be represented as
+ <p>By default, if any requested chunk is missing in
+ <c><anno>Beam</anno></c>, an <c>error</c> tuple is returned.
+ However, if option <c>allow_missing_chunks</c> is specified,
+ a result is returned even if chunks are missing.
+ In the result list, any missing chunks are represented as
<c>{<anno>ChunkRef</anno>,missing_chunk}</c>.
- Note, however, that if the <c>"Atom"</c> chunk if missing, that is
- considered a fatal error and the return value will be an <c>error</c>
+ Notice however that if chunk <c>"Atom"</c> is missing, that is
+ considered a fatal error and the return value is an <c>error</c>
tuple.</p>
</desc>
</func>
+
<func>
- <name name="build_module" arity="1"/>
- <fsummary>Creates a BEAM module from a list of chunks</fsummary>
+ <name name="clear_crypto_key_fun" arity="0"/>
+ <fsummary>Unregister the current crypto key fun.</fsummary>
<desc>
- <p>Builds a BEAM module (as a binary) from a list of chunks.</p>
+ <p>Unregisters the crypto key fun and terminates the process
+ holding it, started by
+ <seealso marker="#crypto_key_fun/1"><c>crypto_key_fun/1</c></seealso>.
+ </p>
+ <p>Returns either <c>{ok, undefined}</c> if no crypto key fun is
+ registered, or <c>{ok, Term}</c>, where <c>Term</c> is
+ the return value from <c>CryptoKeyFun(clear)</c>, see
+ <c>crypto_key_fun/1</c>.</p>
</desc>
</func>
+
<func>
- <name name="version" arity="1"/>
- <fsummary>Read the BEAM file's module version</fsummary>
+ <name name="cmp" arity="2"/>
+ <fsummary>Compare two BEAM files.</fsummary>
+ <type name="cmp_rsn"/>
<desc>
- <p>Returns the module version(s). A version is defined by
- the module attribute <c>-vsn(Vsn)</c>. If this attribute is
- not specified, the version defaults to the checksum of
- the module. Note that if the version <c>Vsn</c> is not a list,
- it is made into one, that is <c>{ok,{Module,[Vsn]}}</c> is
- returned. If there are several <c>-vsn</c> module attributes,
- the result is the concatenated list of versions. Examples:</p>
- <pre>
-1> <input>beam_lib:version(a).</input> % -vsn(1).
-{ok,{a,[1]}}
-2> <input>beam_lib:version(b).</input> % -vsn([1]).
-{ok,{b,[1]}}
-3> <input>beam_lib:version(c).</input> % -vsn([1]). -vsn(2).
-{ok,{c,[1,2]}}
-4> <input>beam_lib:version(d).</input> % no -vsn attribute
-{ok,{d,[275613208176997377698094100858909383631]}}</pre>
+ <p>Compares the contents of two BEAM files. If the module names
+ are the same, and all chunks except for chunk <c>"CInf"</c>
+ (the chunk containing the compilation information that is
+ returned by <c>Module:module_info(compile)</c>)
+ have the same contents in both files,
+ <c>ok</c> is returned. Otherwise an error message is returned.</p>
</desc>
</func>
+
<func>
- <name name="md5" arity="1"/>
- <fsummary>Read the BEAM file's module version</fsummary>
+ <name name="cmp_dirs" arity="2"/>
+ <fsummary>Compare the BEAM files in two directories.</fsummary>
<desc>
- <p>Calculates an MD5 redundancy check for the code of the module
- (compilation date and other attributes are not included).</p>
+ <p>Compares the BEAM files in
+ two directories. Only files with extension <c>".beam"</c> are
+ compared. BEAM files that exist only in directory
+ <c><anno>Dir1</anno></c> (<c><anno>Dir2</anno></c>) are returned in
+ <c><anno>Only1</anno></c> (<c><anno>Only2</anno></c>).
+ BEAM files that exist in both directories but
+ are considered different by <c>cmp/2</c> are returned as
+ pairs {<c><anno>Filename1</anno></c>, <c><anno>Filename2</anno></c>},
+ where <c><anno>Filename1</anno></c> (<c><anno>Filename2</anno></c>)
+ exists in directory <c><anno>Dir1</anno></c>
+ (<c><anno>Dir2</anno></c>).</p>
</desc>
</func>
+
+ <func>
+ <name name="crypto_key_fun" arity="1"/>
+ <fsummary>Register a fun that provides a crypto key.</fsummary>
+ <type name="crypto_fun"/>
+ <type name="crypto_fun_arg"/>
+ <type name="mode"/>
+ <desc>
+ <p>Registers an unary fun
+ that is called if <c>beam_lib</c> must read an
+ <c>abstract_code</c> chunk that has been encrypted. The fun
+ is held in a process that is started by the function.</p>
+ <p>If a fun is already registered when attempting to
+ register a fun, <c>{error, exists}</c> is returned.</p>
+ <p>The fun must handle the following arguments:</p>
+ <code type="none">
+CryptoKeyFun(init) -> ok | {ok, NewCryptoKeyFun} | {error, Term}</code>
+ <p>Called when the fun is registered, in the process that holds
+ the fun. Here the crypto key fun can do any necessary
+ initializations. If <c>{ok, NewCryptoKeyFun}</c> is returned,
+ <c>NewCryptoKeyFun</c> is registered instead of
+ <c>CryptoKeyFun</c>. If <c>{error, Term}</c> is returned,
+ the registration is aborted and <c>crypto_key_fun/1</c>
+ also returns <c>{error, Term}</c>.</p>
+ <code type="none">
+CryptoKeyFun({debug_info, Mode, Module, Filename}) -> Key</code>
+ <p>Called when the key is needed for module <c>Module</c>
+ in the file named <c>Filename</c>. <c>Mode</c> is the type of
+ crypto algorithm; currently, the only possible value is
+ <c>des3_cbc</c>. The call is to fail (raise an exception) if
+ no key is available.</p>
+ <code type="none">
+CryptoKeyFun(clear) -> term()</code>
+ <p>Called before the fun is unregistered. Here any cleaning up
+ can be done. The return value is not important, but is passed
+ back to the caller of <c>clear_crypto_key_fun/0</c> as part
+ of its return value.</p>
+ </desc>
+ </func>
+
+ <func>
+ <name name="diff_dirs" arity="2"/>
+ <fsummary>Compare the BEAM files in two directories.</fsummary>
+ <desc>
+ <p>Compares the BEAM files in two directories as
+ <seealso marker="#cmp_dirs/2"><c>cmp_dirs/2</c></seealso>, but the
+ names of files that exist in only one directory or are different are
+ presented on standard output.</p>
+ </desc>
+ </func>
+
+ <func>
+ <name name="format_error" arity="1"/>
+ <fsummary>Return an English description of a BEAM read error reply.
+ </fsummary>
+ <desc>
+ <p>For a specified error returned by any function in this module,
+ this function returns a descriptive string
+ of the error in English. For file errors, function
+ <seealso marker="kernel:file#format_error/1"><c>file:format_error(Posix)</c></seealso>
+ is to be called.</p>
+ </desc>
+ </func>
+
<func>
<name name="info" arity="1"/>
- <fsummary>Information about a BEAM file</fsummary>
+ <fsummary>Information about a BEAM file.</fsummary>
<desc>
<p>Returns a list containing some information about a BEAM file
as tuples <c>{Item, Info}</c>:</p>
<taglist>
- <tag><c>{file, <anno>Filename</anno>} | {binary, <anno>Binary</anno>}</c></tag>
+ <tag><c>{file, <anno>Filename</anno>} | {binary,
+ <anno>Binary</anno>}</c></tag>
<item>
<p>The name (string) of the BEAM file, or the binary from
which the information was extracted.</p>
@@ -310,7 +417,8 @@
<item>
<p>The name (atom) of the module.</p>
</item>
- <tag><c>{chunks, [{<anno>ChunkId</anno>, <anno>Pos</anno>, <anno>Size</anno>}]}</c></tag>
+ <tag><c>{chunks, [{<anno>ChunkId</anno>, <anno>Pos</anno>,
+ <anno>Size</anno>}]}</c></tag>
<item>
<p>For each chunk, the identifier (string) and the position
and size of the chunk data, in bytes.</p>
@@ -318,135 +426,75 @@
</taglist>
</desc>
</func>
+
<func>
- <name name="cmp" arity="2"/>
- <fsummary>Compare two BEAM files</fsummary>
- <type name="cmp_rsn"/>
- <desc>
- <p>Compares the contents of two BEAM files. If the module names
- are the same, and all chunks except for the <c>"CInf"</c> chunk
- (the chunk containing the compilation information which is
- returned by <c>Module:module_info(compile)</c>)
- have the same contents in both files,
- <c>ok</c> is returned. Otherwise an error message is returned.</p>
- </desc>
- </func>
- <func>
- <name name="cmp_dirs" arity="2"/>
- <fsummary>Compare the BEAM files in two directories</fsummary>
- <desc>
- <p>The <c>cmp_dirs/2</c> function compares the BEAM files in
- two directories. Only files with extension <c>".beam"</c> are
- compared. BEAM files that exist in directory <c><anno>Dir1</anno></c>
- (<c><anno>Dir2</anno></c>) only are returned in <c><anno>Only1</anno></c>
- (<c><anno>Only2</anno></c>). BEAM files that exist on both directories but
- are considered different by <c>cmp/2</c> are returned as
- pairs {<c><anno>Filename1</anno></c>, <c><anno>Filename2</anno></c>} where
- <c><anno>Filename1</anno></c> (<c><anno>Filename2</anno></c>) exists in directory
- <c><anno>Dir1</anno></c> (<c><anno>Dir2</anno></c>).</p>
- </desc>
- </func>
- <func>
- <name name="diff_dirs" arity="2"/>
- <fsummary>Compare the BEAM files in two directories</fsummary>
+ <name name="md5" arity="1"/>
+ <fsummary>Read the module version of the BEAM file.</fsummary>
<desc>
- <p>The <c>diff_dirs/2</c> function compares the BEAM files in
- two directories the way <c>cmp_dirs/2</c> does, but names of
- files that exist in only one directory or are different are
- presented on standard output.</p>
+ <p>Calculates an MD5 redundancy check for the code of the module
+ (compilation date and other attributes are not included).</p>
</desc>
</func>
+
<func>
<name name="strip" arity="1"/>
- <fsummary>Removes chunks not needed by the loader from a BEAM file</fsummary>
+ <fsummary>Remove chunks not needed by the loader from a BEAM file.
+ </fsummary>
<desc>
- <p>The <c>strip/1</c> function removes all chunks from a BEAM
+ <p>Removes all chunks from a BEAM
file except those needed by the loader. In particular,
- the debug information (<c>abstract_code</c> chunk) is removed.</p>
+ the debug information (chunk <c>abstract_code</c>) is removed.</p>
</desc>
</func>
+
<func>
<name name="strip_files" arity="1"/>
- <fsummary>Removes chunks not needed by the loader from BEAM files</fsummary>
+ <fsummary>Removes chunks not needed by the loader from BEAM files.
+ </fsummary>
<desc>
- <p>The <c>strip_files/1</c> function removes all chunks except
+ <p>Removes all chunks except
those needed by the loader from BEAM files. In particular,
- the debug information (<c>abstract_code</c> chunk) is removed.
- The returned list contains one element for each given file
- name, in the same order as in <c>Files</c>.</p>
+ the debug information (chunk <c>abstract_code</c>) is removed.
+ The returned list contains one element for each specified filename,
+ in the same order as in <c>Files</c>.</p>
</desc>
</func>
+
<func>
<name name="strip_release" arity="1"/>
- <fsummary>Removes chunks not needed by the loader from all BEAM files of a release</fsummary>
+ <fsummary>Remove chunks not needed by the loader from all BEAM files of
+ a release.</fsummary>
<desc>
- <p>The <c>strip_release/1</c> function removes all chunks
+ <p>Removes all chunks
except those needed by the loader from the BEAM files of a
- release. <c><anno>Dir</anno></c> should be the installation root
+ release. <c><anno>Dir</anno></c> is to be the installation root
directory. For example, the current OTP release can be
stripped with the call
<c>beam_lib:strip_release(code:root_dir())</c>.</p>
</desc>
</func>
+
<func>
- <name name="format_error" arity="1"/>
- <fsummary>Return an English description of a BEAM read error reply</fsummary>
- <desc>
- <p>Given the error returned by any function in this module,
- the function <c>format_error</c> returns a descriptive string
- of the error in English. For file errors, the function
- <c>file:format_error(Posix)</c> should be called.</p>
- </desc>
- </func>
- <func>
- <name name="crypto_key_fun" arity="1"/>
- <fsummary>Register a fun that provides a crypto key</fsummary>
- <type name="crypto_fun"/>
- <type name="crypto_fun_arg"/>
- <type name="mode"/>
- <desc>
- <p>The <c>crypto_key_fun/1</c> function registers a unary fun
- that will be called if <c>beam_lib</c> needs to read an
- <c>abstract_code</c> chunk that has been encrypted. The fun
- is held in a process that is started by the function.</p>
- <p>If there already is a fun registered when attempting to
- register a fun, <c>{error, exists}</c> is returned.</p>
- <p>The fun must handle the following arguments:</p>
- <code type="none">
- CryptoKeyFun(init) -> ok | {ok, NewCryptoKeyFun} | {error, Term}</code>
- <p>Called when the fun is registered, in the process that holds
- the fun. Here the crypto key fun can do any necessary
- initializations. If <c>{ok, NewCryptoKeyFun}</c> is returned
- then <c>NewCryptoKeyFun</c> will be registered instead of
- <c>CryptoKeyFun</c>. If <c>{error, Term}</c> is returned,
- the registration is aborted and <c>crypto_key_fun/1</c>
- returns <c>{error, Term}</c> as well.</p>
- <code type="none">
- CryptoKeyFun({debug_info, Mode, Module, Filename}) -> Key</code>
- <p>Called when the key is needed for the module <c>Module</c>
- in the file named <c>Filename</c>. <c>Mode</c> is the type of
- crypto algorithm; currently, the only possible value thus is
- <c>des3_cbc</c>. The call should fail (raise an exception) if
- there is no key available.</p>
- <code type="none">
- CryptoKeyFun(clear) -> term()</code>
- <p>Called before the fun is unregistered. Here any cleaning up
- can be done. The return value is not important, but is passed
- back to the caller of <c>clear_crypto_key_fun/0</c> as part
- of its return value.</p>
- </desc>
- </func>
- <func>
- <name name="clear_crypto_key_fun" arity="0"/>
- <fsummary>Unregister the current crypto key fun</fsummary>
+ <name name="version" arity="1"/>
+ <fsummary>Read the module version of the BEAM file.</fsummary>
<desc>
- <p>Unregisters the crypto key fun and terminates the process
- holding it, started by <c>crypto_key_fun/1</c>.</p>
- <p>The <c>clear_crypto_key_fun/1</c> either returns
- <c>{ok, undefined}</c> if there was no crypto key fun
- registered, or <c>{ok, Term}</c>, where <c>Term</c> is
- the return value from <c>CryptoKeyFun(clear)</c>, see
- <c>crypto_key_fun/1</c>.</p>
+ <p>Returns the module version or versions. A version is defined by
+ module attribute <c>-vsn(Vsn)</c>. If this attribute is
+ not specified, the version defaults to the checksum of
+ the module. Notice that if version <c>Vsn</c> is not a list,
+ it is made into one, that is <c>{ok,{Module,[Vsn]}}</c> is
+ returned. If there are many <c>-vsn</c> module attributes,
+ the result is the concatenated list of versions.</p>
+ <p><em>Examples:</em></p>
+ <pre>
+1> <input>beam_lib:version(a).</input> % -vsn(1).
+{ok,{a,[1]}}
+2> <input>beam_lib:version(b).</input> % -vsn([1]).
+{ok,{b,[1]}}
+3> <input>beam_lib:version(c).</input> % -vsn([1]). -vsn(2).
+{ok,{c,[1,2]}}
+4> <input>beam_lib:version(d).</input> % no -vsn attribute
+{ok,{d,[275613208176997377698094100858909383631]}}</pre>
</desc>
</func>
</funcs>