From d16a480a43a858d604d1ac8d644589be3f49dda1 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Bj=C3=B6rn=20Gustavsson?= Date: Thu, 23 Jan 2014 17:36:57 +0100 Subject: Update documentation --- lib/asn1/doc/src/asn1_ug.xml | 90 ++++++++++++++++++++------------------------ 1 file changed, 40 insertions(+), 50 deletions(-) (limited to 'lib/asn1/doc/src/asn1_ug.xml') diff --git a/lib/asn1/doc/src/asn1_ug.xml b/lib/asn1/doc/src/asn1_ug.xml index 74c4aa9948..eb9f000e75 100644 --- a/lib/asn1/doc/src/asn1_ug.xml +++ b/lib/asn1/doc/src/asn1_ug.xml @@ -653,7 +653,7 @@ Day1 = saturday, Bits1 ::= BIT STRING Bits2 ::= BIT STRING {foo(0),bar(1),gnu(2),gnome(3),punk(14)} -

There are five different notations available for representation of +

There are two notations available for representation of BIT STRING values in Erlang and as input to the encode functions.

A bitstring. By default, a BIT STRING with no @@ -661,43 +661,10 @@ Bits2 ::= BIT STRING {foo(0),bar(1),gnu(2),gnome(3),punk(14)} A list of atoms corresponding to atoms in the NamedBitList in the BIT STRING definition. A BIT STRING with symbolic names will always be decoded to this format. - A list of binary digits (0 or 1). This format is always - accepted as input to the encode functions. A BIT STRING will - be decoded to this format if legacy_bit_string option - has been given. This format may be withdrawn in a future - release. - - As {Unused,Binary} where Unused denotes how - many trailing zero-bits 0 to 7 that are unused in the least - significant byte in Binary. This format is always - accepted as input to the encode functions. A BIT STRING will - be decoded to this format if compact_bit_string has - been given. This format may be withdrawn in a future - release. - - A hexadecimal number (or an integer). This format should be - avoided, since it is easy to misinterpret a BIT STRING - value in this format. This format may be withdrawn in a future - release. - - -

It is recommended to either use the bitstring format (for - BIT STRINGs with no symbolic names) or a list of symbolic - names (for BIT STRINGs with symbolic names). The other formats - should be avoided since they may be withdrawn in a future - release. -

- +

Example:

 Bits1Val1 = <<0:1,1:1,0:1,1:1,1:1>>,
-Bits1Val2 = 16#1A,
-Bits1Val3 = {3,<<0:1,1:1,0:1,1:1,1:1,0:3>>},
-Bits1Val4 = [0,1,0,1,1]
-
-

Note that Bits1Val1, Bits1Val2, Bits1Val3, - and Bits1Val1 denote the same value.

- 
 Bits2Val1 = [gnu,punk],
 Bits2Val2 = <<2#1110:4>>,
 Bits2Val3 = [bar,gnu,gnome],
@@ -708,37 +675,60 @@ Bits2Val3 = [bar,gnu,gnome],
         2 and 14 are set to 1 and the rest set to 0. The symbolic values
         appear as a list of values. If a named value appears, which is not
         specified in the type definition, a run-time error will occur.

-      
The compact notation equivalent to the empty BIT STRING is
-        >}]]>, which in the other notations is
-	>]]>, [], or
-        0.

       
BIT STRINGS may also be sub-typed with, for example, a SIZE
         specification:

       
 Bits3 ::= BIT STRING (SIZE(0..31))      

       
This means that no bit higher than 31 can ever be set.

+
+      

+	Deprecated representations for BIT STRING
+	
In addition to the representations described above, the
+	following deprecated representations are available if the
+	specification has been compiled with the
+	legacy_erlang_types option:

+	
+	  A list of binary digits (0 or 1). This format is
+	  accepted as input to the encode functions, and a BIT STRING
+	  will be decoded to this format if the
+	  legacy_bit_string option has been given.
+	  
+	  As {Unused,Binary} where Unused denotes
+	  how many trailing zero-bits 0 to 7 that are unused in the
+	  least significant byte in Binary. This format is
+	  accepted as input to the encode functions, and a BIT
+	  STRING will be decoded to this format if
+	  compact_bit_string has been given.
+	  
+	  A hexadecimal number (or an integer). This format
+	  should be avoided, since it is easy to misinterpret a BIT
+	  STRING value in this format.
+	  
+	
+      

     
 
     

       
       OCTET STRING
-      
The OCTET STRING is the simplest of all ASN.1 types The OCTET STRING
-        only moves or transfers e.g. binary files or other unstructured
-        information complying to two rules.
-        Firstly, the bytes consist of octets and secondly, encoding is 
-        not required.

+      
The OCTET STRING is the simplest of all ASN.1 types. The
+      OCTET STRING only moves or transfers e.g. binary files or other
+      unstructured information complying to two rules.  Firstly, the
+      bytes consist of octets and secondly, encoding is not
+      required.

       
It is possible to have the following ASN.1 type definitions:

       
 O1 ::= OCTET STRING
 O2 ::= OCTET STRING (SIZE(28))      

       
With the following example assignments in Erlang:

       
-O1Val = [17,13,19,20,0,0,255,254],
-O2Val = "must be exactly 28 chars....",      

-      
Observe that O1Val is assigned a series of numbers between 0 
-        and 255 i.e. octets.
-        O2Val is assigned using the string notation.
-        

+O1Val = <<17,13,19,20,0,0,255,254>>,
+O2Val = <<"must be exactly 28 chars....">>,
+

By default, an OCTET STRING is always represented as + an Erlang binary. If the specification has been compiled with + the legacy_erlang_types option, the encode functions + will accept both lists and binaries, and the decode functions + will decode an OCTET STRING to a list.

-- cgit v1.2.3