The R13B03 release.OTP_R13B03

8 files changed, 413 insertions, 0 deletions

diff --git a/lib/asn1/examples/InfClass3.asn b/lib/asn1/examples/InfClass3.asn
new file mode 100644
index 0000000000..6c1fd0f430
--- /dev/null
+++ b/lib/asn1/examples/InfClass3.asn
@@ -0,0 +1,36 @@
+InfClass3 DEFINITIONS  ::=
+BEGIN
+
+FUNCTION ::= CLASS {
+    &ArgumentType,
+    &ResultType   DEFAULT NULL,
+    &code         INTEGER
+    }
+
+ObjSet1 FUNCTION ::= { ... }
+
+object1 FUNCTION ::= {
+    &ArgumentType  INTEGER,
+    &ResultType    INTEGER,
+    &code          3
+    }
+
+object2 FUNCTION ::= {
+    &ArgumentType  INTEGER,
+    &ResultType    INTEGER,
+    &code          2
+    }
+
+
+ObjSet2 FUNCTION ::= {
+    object1 | object2 }
+
+ParamType{FUNCTION:object} ::=SEQUENCE
+{
+   val1    INTEGER,
+   val2    object.&ArgumentType
+   }
+
+parTypVal{FUNCTION:object2} ParamType ::= {1,2}
+ 
+END
diff --git a/lib/asn1/examples/Int.py b/lib/asn1/examples/Int.py
new file mode 100644
index 0000000000..490d5a16ea
--- /dev/null
+++ b/lib/asn1/examples/Int.py
@@ -0,0 +1,30 @@
+Int DEFINITIONS  ::=

+BEGIN

+

+-- F.2.2.2 

+-- Define the minimum and maximum allowed values of an integer type 

+-- as named numbers.

+-- EXAMPLE

+

+	DayOfTheMonth ::= INTEGER {first(1), last(31)}

+	today DayOfTheMonth ::= first

+	unknown DayOfTheMonth ::= 0

+

+-- To restrict the value of DayOfTheMonth to just "first" and "last", 

+-- one would write:

+

+	DayOfTheMonth2 ::= INTEGER {first(1), last(31)} (first | last)

+

+-- and to restrict the value of the DayOfTheMonth to all values 

+-- between 1 and 31, inclusive, one would write:

+

+	DayOfTheMonth3 ::= INTEGER {first(1), last(31)} (first .. last)

+	dayOfTheMonth DayOfTheMonth3 ::= 4

+
+	SmallInt ::= INTEGER (0..1000)
+	OrInt ::= INTEGER (10 | 20 | 30)
+
+	small SmallInt ::= 17
+	or OrInt ::= 20
+

+END

diff --git a/lib/asn1/examples/P-Record.asn b/lib/asn1/examples/P-Record.asn
new file mode 100644
index 0000000000..13643efef3
--- /dev/null
+++ b/lib/asn1/examples/P-Record.asn
@@ -0,0 +1,59 @@
+P-Record DEFINITIONS  ::=
+BEGIN
+
+
+PersonnelRecord ::= [APPLICATION 0] SET
+{	name			  Name,
+	title			  VisibleString,
+	number			  EmployeeNumber,
+	dateOfHire		  Date,
+	nameOfSpouse  	[1]	  Name,
+	children		  SEQUENCE OF ChildInformation DEFAULT {}
+}
+
+ChildInformation ::= SET
+{	name			Name OPTIONAL,
+	dateOfBirth		Date OPTIONAL
+}
+
+Name ::= [APPLICATION 1] SEQUENCE
+{	givenName		VisibleString,
+	initial			VisibleString,
+	familyName		VisibleString
+}
+
+EmployeeNumber ::= [APPLICATION 2] INTEGER
+Date ::= [APPLICATION 3] VisibleString  --  YYYY MMDD
+
+v PersonnelRecord ::=
+{
+	name {
+		givenName "John", 
+		initial "P", 
+		familyName "Smith"
+	},
+	title	"Director",
+	number	51,
+	dateOfHire "19710917",
+	nameOfSpouse {
+		givenName "Mary", 
+		initial "T", 
+		familyName "Smith"
+	},
+	children { 
+		{name {
+			givenName "Ralph", 
+			initial "T", 
+			familyName "Smith"
+		} ,
+		dateOfBirth "19571111"},
+		{name {
+			givenName "Susan", 
+			initial "B", 
+			familyName "Jones"
+		} ,
+		dateOfBirth "19590717" }
+	}
+}
+
+END
diff --git a/lib/asn1/examples/RANAPextract1.asn b/lib/asn1/examples/RANAPextract1.asn
new file mode 100644
index 0000000000..fdd33d6027
--- /dev/null
+++ b/lib/asn1/examples/RANAPextract1.asn
@@ -0,0 +1,101 @@
+RANAPextract1 DEFINITIONS ::=
+BEGIN
+
+
+RANAP-ELEMENTARY-PROCEDURE ::= CLASS {
+  &InitiatingMessage				,
+  &SuccessfulOutcome				OPTIONAL,
+  &UnsuccessfulOutcome				OPTIONAL,
+  &Outcome					OPTIONAL,
+  &procedureCode			ProcedureCode 	UNIQUE,
+  &criticality			Criticality 	DEFAULT ignore
+}
+WITH SYNTAX {
+  INITIATING MESSAGE		&InitiatingMessage
+  [SUCCESSFUL OUTCOME		&SuccessfulOutcome]
+  [UNSUCCESSFUL OUTCOME		&UnsuccessfulOutcome]
+  [OUTCOME			&Outcome]
+  PROCEDURE CODE				&procedureCode
+  [CRITICALITY			&criticality]
+}
+
+RANAP-PDU ::= CHOICE {
+  initiatingMessage	InitiatingMessage,
+  --	successfulOutcome	SuccessfulOutcome,
+  --	unsuccessfulOutcome	UnsuccessfulOutcome,
+  --	outcome			Outcome,
+  ...
+}
+
+InitiatingMessage  ::= SEQUENCE {
+  procedureCode  RANAP-ELEMENTARY-PROCEDURE.&procedureCode	({RANAP-ELEMENTARY-PROCEDURES}),
+  criticality	RANAP-ELEMENTARY-PROCEDURE.&criticality		({RANAP-ELEMENTARY-PROCEDURES}{@procedureCode}),
+  value	RANAP-ELEMENTARY-PROCEDURE.&InitiatingMessage	({RANAP-ELEMENTARY-PROCEDURES}{@procedureCode})
+}
+
+iu-Release RANAP-ELEMENTARY-PROCEDURE ::= {
+  INITIATING MESSAGE	Iu-ReleaseCommand
+  SUCCESSFUL OUTCOME	Iu-ReleaseComplete
+  PROCEDURE CODE	id-Iu-Release
+  CRITICALITY		ignore
+}
+
+relocationPreparation RANAP-ELEMENTARY-PROCEDURE ::= {
+  INITIATING MESSAGE	Iu-ReleaseCommand
+  SUCCESSFUL OUTCOME	Iu-ReleaseComplete
+  PROCEDURE CODE	id-relocationPreparation
+  CRITICALITY		notify
+}
+
+testObject RANAP-ELEMENTARY-PROCEDURE ::= {
+  INITIATING MESSAGE	Iu-ReleaseCommand
+  SUCCESSFUL OUTCOME	Iu-ReleaseComplete
+  PROCEDURE CODE	id-test
+  CRITICALITY		notify
+}
+
+testObject2 RANAP-ELEMENTARY-PROCEDURE ::= {
+  INITIATING MESSAGE	Iu-ReleaseCommand
+  SUCCESSFUL OUTCOME	Iu-ReleaseComplete
+  PROCEDURE CODE	id-test2
+  CRITICALITY		notify
+}
+
+RANAP-ELEMENTARY-PROCEDURES RANAP-ELEMENTARY-PROCEDURE ::= {
+  iu-Release         |
+  relocationPreparation ,
+  ...
+}
+
+RANAP-ELEMENTARY-PROCEDURES2 RANAP-ELEMENTARY-PROCEDURE ::= {
+  {INITIATING MESSAGE	Iu-ReleaseCommand
+  SUCCESSFUL OUTCOME	Iu-ReleaseComplete
+  PROCEDURE CODE	id-test
+  CRITICALITY		notify}
+} 
+
+RANAP-ELEMENTARY-PROCEDURES3 RANAP-ELEMENTARY-PROCEDURE ::= {
+  iu-Release|
+  testObject,
+  ...,
+  relocationPreparation |
+  testObject2
+}
+
+Iu-ReleaseCommand  ::= SEQUENCE {
+  first     INTEGER,
+  second    BOOLEAN
+}
+
+Iu-ReleaseComplete ::= INTEGER (1..510)
+
+ProcedureCode      ::= INTEGER (0..255)
+Criticality        ::= ENUMERATED { reject, ignore, notify }
+id-Iu-Release		  INTEGER ::= 1
+id-relocationPreparation  INTEGER ::= 2
+id-test   INTEGER ::= 3
+id-test2   INTEGER ::= 4
+
+END
+
+
diff --git a/lib/asn1/examples/ecn_internaldoc.txt b/lib/asn1/examples/ecn_internaldoc.txt
new file mode 100644
index 0000000000..71e2b7a2f1
--- /dev/null
+++ b/lib/asn1/examples/ecn_internaldoc.txt
@@ -0,0 +1,74 @@
+The ECN specification (X.692) describes how to make encodings
+different from the standardised methods, BER and PER with variants.
+
+ECN has a system with inter-working modules including ordinary ASN1
+specs. There are any number of EDM (Encoding Definition Module)
+modules. And always one ELM (Encoding Link Module).
+
+The EDMs contains definitions of encoding classes, encoding objects
+and encoding object sets. They may also have IMPORTS and EXPORTS
+clauses. Encoding classes tells the structure of the encoding. Besides
+classes corresponding to types there are classes that define
+determinants for length and presence. The objects tell how the actual
+type that will be mapped to this object is encoded.
+
+The ELM is the module that links (applies) the various encodings,
+defined in the EDMs, to the types in the ASN1 specs.
+
+The ASN1 specs are not affected by being part of an ECN application.
+
+The following requirements must be wholly or partly fulfilled to
+enable the use of ECN in the OTP ASN1 compiler.
+       - Parsing of EDM and ELM modules.
+       - Extend the format of the abstract syntax tree or in other way
+       pass encoding information to code generation.
+       - Make possible to generate code with different encoding
+       methods.
+       - Unaligned PER backend. Often seems the unaligned PER encoding
+       as the prefferred main method in ECN applications. One of the
+       goals with ECN is to use less space for encoding to decrease
+       the use of bandwith in transmission. This goal is highly
+       supported by unaligned PER.
+
+
+Parsing of EDM and ELM modules:
+This should be done in a different parser than by the ASN1
+asn1ct_parser2.erl. The ECN syntax is quite extensive. A deeper
+investigation must be done here.
+
+Extend format of abstract syntax:
+To derive this format one has to consider both the explicit and
+implicit defined encoding structures.
+This addition of information should maybe be done after the check
+phase of the ASN1 syntax.
+
+Code generation:
+Initially one can just generate call-back functions when the encoding
+differs from the default method. Nevertheless the information must be
+present in the sytax tree so far. When the full functionality is
+implemented one has to enable a finer granularity in the use of the
+encoding rules. And also enable control of encoding on bit level.
+
+Unaligned PER backend:
+Often in examples this variant of PER is used. It shouldn't be that
+much work to add this encoding. Probably this will benefit the use of
+the driver.
+
+
+ECN can be used in for instance:
+    - Protocol systems that is not an ASN1 protocol.
+    - Specialized ASN1 protocols.
+
+
+Need for ECN?
+
+Among the ASN1 systems that have been enabled for ECN are:
+UMTS,
+Bluetooth,
+GPRS,
+CAMEL phase 3 stage 2,
+SS7,
+SCCP,
+and others.
+
+Inswitch has asked for it.
diff --git a/lib/asn1/examples/encode_decode_formats.txt b/lib/asn1/examples/encode_decode_formats.txt
new file mode 100644
index 0000000000..62774cf13b
--- /dev/null
+++ b/lib/asn1/examples/encode_decode_formats.txt
@@ -0,0 +1,16 @@
+Compile options:	      |		encode output |	decode input	|
+------------------------------+-----------------------+-----------------|
+ber (default)		      |		flat list     | flat list,binary|
+ber_bin			      |		iolist	      | binary		|
+ber_bin,optimize	      | 	iolist	      | binary		|
+ber_bin,optimize,driver	      | 	iolist	      | iolist,binary	|
+per			      | 	flat list     | flat list       |
+per_bin			      | 	deep list     | binary	        |
+per_bin, optimize	      | 	binary	      | binary	        |
+------------------------------+-----------------------+-----------------+   
+								         
+								            
+
+
+
+iolist: deep list with binaries and lists as componets
\ No newline at end of file
diff --git a/lib/asn1/examples/recordnames.txt b/lib/asn1/examples/recordnames.txt
new file mode 100644
index 0000000000..78e30ab510
--- /dev/null
+++ b/lib/asn1/examples/recordnames.txt
@@ -0,0 +1,51 @@
+For each ASN1 types SET and SEQUENCE a record is generated in the .hrl
+file with the same name as the corresponding type.
+A decoded value is also returned as a record with the apropriate name.
+An internally defined type as the type in component 'a' in the
+following example will result in a record with name 'Seq_a':
+
+Seq ::= SEQUENCE{
+    a	SEQUENCE{
+	b INTEGER
+	}
+}
+
+For each further internally defined type in a SET/SEQUENCE a
+'_componentname' is added.
+
+If an internally defined type is an CHOICE alternative the record name
+will get the alternative name as a unique part of the name.
+
+Seq ::= SEQUENCE{
+    a	CHOICE{
+	b SEQUENCE {
+	   c  INTEGER
+	   }
+	}
+}
+
+This will produece a record 'Seq_a_b'.
+
+If an component is a SEQUENCE OF a SEQUENCE as in:
+Seq ::= SEQUENCE {
+    a SEQUENCE OF SEQUENCE {
+	       b
+	       }
+    c SET OF SEQUENCE {
+	     d
+	     }
+}
+There will be a record 'Seq_a_SEQOF' and 'Seq_c_SETOF'
+
+A parameterized type should be considered as an internally defined
+type. Each time a such type is referenced an instance of it is
+defined. Thus in the following example a record 'Seq_b' is generated
+in .hrl and used in .erl by decode.
+
+Seq ::= SEQUENCE {
+    b PType{INTEGER}
+}
+
+PType{T} ::= SEQUENCE{
+    id T
+}
\ No newline at end of file
diff --git a/lib/asn1/examples/test_driver.erl b/lib/asn1/examples/test_driver.erl
new file mode 100644
index 0000000000..2bbdce4934
--- /dev/null
+++ b/lib/asn1/examples/test_driver.erl
@@ -0,0 +1,46 @@
+%%%-------------------------------------------------------------------
+%%% File    : test_driver.erl
+%%% Author  : Bertil Karlsson <bertil@finrod>
+%%% Description : 
+%%%
+%%% Created : 27 Mar 2002 by Bertil Karlsson <bertil@finrod>
+%%%-------------------------------------------------------------------
+-module(test_driver).
+
+-export([start/0, start/1, init/1, complete/1,complete/0]).
+
+start() ->
+    start("asn1_erl_drv").
+
+start(SharedLib) ->
+    case erl_ddll:load_driver("../priv/bin/", SharedLib) of
+	ok -> ok;
+	{error, already_loaded} -> ok;
+	Error -> exit({error, could_not_load_driver,Error})
+    end,
+    spawn(?MODULE, init, [SharedLib]).
+
+init(SharedLib) ->
+    Port = open_port({spawn, SharedLib}, []),
+    register(drv_complete,Port),
+    register(compl_pid,self()),
+    receive
+	stop ->
+	    exit(goodbye)
+    end.
+
+complete(Data) ->
+    Ret=port_control(drv_complete,1,Data),
+    io:format("complete result:~n~p~n",[Ret]).
+
+complete() ->
+    %% The result should be <<64,192,17,17,24,96>>
+    Data1 = [<<0:8>>,<<1:8>>,<<2:8>>,<<10:8,2:8,3:8>>,<<20:8,2:8,17:8,17:8>>,<<30:8,2:8,1:8,24:8>>,<<31:8,2:8,0:8,1:8,24:8>>,<<2:8>>],
+    complete(Data1),
+    io:format("should have been:~n<<64,192,17,17,24,96>>~n"),
+    Data2 = [40,8,8,1,0,1,0,1,0,1,0,0,2,1,45,8,1,170,45,7,1,170],
+    complete(Data2),
+    io:format("should have been:~n<<170,0,213,85>>~n"),
+    Data3 = [40,8,8,1,0,1,0,1,0,1,0,0,2,1,45,8,1,170,45,8,1,170],
+    complete(Data3),
+    io:format("should have been:~n<<170,0,213,85,0>>~n").