From 953b858de46f46f42e2ba45ba30a9b0b278a526d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Bj=C3=B6rn=20Gustavsson?= Date: Mon, 17 Dec 2012 16:25:59 +0100 Subject: Remove the 'inline' and '{inline,OutputFile}' options --- lib/asn1/doc/src/asn1_ug.xml | 43 ++----------------------------------------- 1 file changed, 2 insertions(+), 41 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 6cb251c3e2..ecca287670 100644 --- a/lib/asn1/doc/src/asn1_ug.xml +++ b/lib/asn1/doc/src/asn1_ug.xml @@ -352,22 +352,6 @@ erlc -o ../asnfiles -I ../asnfiles -I /usr/local/standards/asn1 Person.asn list or a binary. Earlier versions of the compiler ignored those following bytes.

- {inline,OutputName} - -

Compiling with this option gives one output module - containing all asn1 run-time functionality. The asn1 specs - are provided in a target module Module.set.asn as - described in the reference manual. The name of the resulting module - containing generated encode/decode functions and inlined - run-time functions will be OutputName.erl. The - merging/inlining of code is done by the igor module - of syntax_tools. By default the functions generated - from the first asn1 spec in the .set.asn are - exported, unless a {export,[atom()]} or - {export_all,true} option are provided. The list of - atoms are names of choosen asn1 specs from the - .set.asn file. See further examples of usage below

- +'Any Erlc Option'

You may add any option to the Erlang compiler when @@ -454,21 +438,8 @@ asn1rt:decode('H323-MESSAGES','SomeChoiceType',Bytes). any reason. Maybe you need to compile the same specs for different encoding/decoding standards. You want only one resulting module. - If it is crucial to have a minimal system. Using - {inline,OutputModule} includes all necessary run-time - functions of the asn1 application, but skips those modules not - used. - Upgrading issues: Even if you upgrade your Erlang system - you may want to continue running the old asn1 run-time - functionality. - Performance issues: If you have an asn1 system with a lot - of cross references you may gain in performance. Measurements - must be done for each case. -

You may choose either the plain multi file compilation that just - merges the chosen asn1 specs or the {inline,OutputModule} - that also includes the used asn1 run-time functionality.

-

For both cases you need to specify which asn1 specs you will +

You need to specify which asn1 specs you will compile in a module that must have the extension .set.asn. You chose name of the module and provide the names of the asn1 specs. For instance, if you have the specs @@ -482,17 +453,7 @@ File3.asn ~> erlc MyModule.set.asn

the result will be one merged module MyModule.erl with - the generated code from the three asn1 specs. But if you compile - with:

- -~> erlc +"{inline,'OutputModule'}" MyModule.set.asn -

the result will be a module OutputModule.erl that - contains all encode/decode functions for the three asn1 specs and - all used functions from the asn1 run-time modules, in this case - asn1rt_ber_bin. In the former case all encode/decode - functions are exported but in the latter only the encode/decode - functions of the first spec in the .set.asn, i.e. those - from File1.asn. + the generated code from the three asn1 specs.

-- cgit v1.2.3 From 74cee7dc1cc5b0332cd851da4953ebbb98224b5f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Bj=C3=B6rn=20Gustavsson?= Date: Tue, 8 Jan 2013 10:56:27 +0100 Subject: By default, encode BIT STRING to bitstrings Add the option 'legacy_bit_string' to decode to the old list format. --- lib/asn1/doc/src/asn1_ug.xml | 77 +++++++++++++++++++++++--------------------- 1 file changed, 40 insertions(+), 37 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 ecca287670..a0ab98cf7a 100644 --- a/lib/asn1/doc/src/asn1_ug.xml +++ b/lib/asn1/doc/src/asn1_ug.xml @@ -324,13 +324,6 @@ erlc -o ../asnfiles -I ../asnfiles -I /usr/local/standards/asn1 Person.asn are several places to search in. The compiler will always search the current directory first.

 - +compact_bit_string - -

Gives the user the option to use a compact format of the BIT - STRING type to save memory space, typing space and - increase encode/decode performance, for details see - BIT STRING type section.

- +der

DER encoding rule. Only when using -ber option.

@@ -649,7 +642,7 @@ Day1 = saturday,
- BIT STRING + BIT STRING

The BIT STRING type can be used to model information which is made up of arbitrary length series of bits. It is intended to be used for a selection of flags, not for binary files.

@@ -660,56 +653,66 @@ Day1 = saturday, Bits1 ::= BIT STRING Bits2 ::= BIT STRING {foo(0),bar(1),gnu(2),gnome(3),punk(14)} -

There are four different notations available for representation of +

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

- A list of binary digits (0 or 1). - 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. + A bitstring. By default, a BIT STRING with no + symbolic names will be decoded to an Erlang bitstring. A list of atoms corresponding to atoms in the NamedBitList - in the BIT STRING definition. + 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 notation is only - available when the ASN.1 files have been compiled with the - +compact_bit_string flag in the option list. In - this case it is possible to use all kinds of notation when - encoding. But the result when decoding is always in the - compact form. The benefit from this notation is a more - compact notation when one has large BIT STRINGs. The - encode/decode performance is also much better in the case of - large BIT STRINGs. + 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. + -

Note that it is advised not to use the integer format of a - BIT STRING, see the second point above.

+

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

-Bits1Val1 = [0,1,0,1,1],
+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>>}
+Bits1Val3 = {3,<<0:1,1:1,0:1,1:1,1:1,0:3>>},
+Bits1Val4 = [0,1,0,1,1]
-

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

+

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

 Bits2Val1 = [gnu,punk],
-Bits2Val2 = 2#1110,
+Bits2Val2 = <<2#1110:4>>,
 Bits2Val3 = [bar,gnu,gnome],
-Bits2Val4 = [0,1,1,1]
-

The above Bits2Val2, Bits2Val3 and Bits2Val4 - also all denote the same value.

+

Bits2Val2 and Bits2Val3 above denote the same value.

Bits2Val1 is assigned symbolic values. The assignment means that the bits corresponding to gnu and punk i.e. bits 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 + >}]]>, which in the other notations is + >]]>, [], or 0.

-

BIT STRINGS may also be sub-typed with for example a SIZE +

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

 Bits3 ::= BIT STRING (SIZE(0..31))
-- cgit v1.2.3