ASN1C COMPILER FAQ
For questions regarding ASN1C licensing, please see our ASN1C Compiler Licensing FAQ.
The following are some frequently asked questions and answers about the ASN1C compiler:
What types of ASN.1 specifications has your product been used on?
How does ASN1C handle Information Objects and Parameterized Types?
Does ASN1C support table constraints as specified in X.682?
Is the source-code generated by ASN1C portable?
Can the code be used in real-time, embedded system applications?
Does ASN1C support all syntax specified in the ASN.1 standards?
Is the the code considered to be Open Source?
Does ASN1C support ROSE macros?
Does ASN1C support X.694 translation of XML schema to ASN.1?
Why is code not generated for types in the CAMEL Application Part (CAP) specification?
Why are the names of some of the generated items so long?
How can I specify different integer types for modules or productions in an ASN.1 specification?
| Q. | What types of ASN.1 specifications has your product been used on? |
| A. |
The ASN1C ASN.1 compiler has been used in a wide variety of
projects involving both custom and standardized ASN.1
specifications. Some of the standard specifications are the
following:
|
| Q. | How does ASN1C handle Information Objects and Parameterized Types? |
| A. | The ASN1C compiler gets at the main type
definitions contained within these definitions and generates
accurate C/C++ and/or Java encoders/decoders for these types.
This sometimes involves linking back through layers of
parameterized definitions and classes to get to the base
types. The compiler is also capable of pulling embedded type
and value definitions from information objects and generating
code for them. Please download our white-paper ASN1C Support for Information Objects and Parameterized Types for further details. |
| Q. | Does ASN1C support table constraints as specified in X.682? |
| A. | ASN1C has the capability to parse and generate code for table constraints. These are constraints on multi-part message types that define the items that can appear in certain parts of a message to values in tables defined within a specification. ASN1C can generate code to make use of these tables that allow these types of messages to be encoded or decoded in a single step. This is done by adding the -tables qualifier to the ASN1C command line when generating code for these types of specifications. |
| Q. | Is the source-code generated by ASN1C portable? |
| A. | Yes, generated C and C++ code is compliant with the American National Standards Institute (ANSI) standards. In the C++ version, the use of non-portable constructs such as templates, I/O stream operators, and exceptions is avoided to ensure maximum portability. A version of the run-time libraries is available that includes source code and it too is ANSI-standard making it possible to port the ASN1C code to a wide-variety of platforms. |
| Q. | Can the code be used in real-time, embedded system applications? |
| A. | We can provide C/C++ binary libraries for certain embedded targets as well as compact libraries for Java or C#. Source code can be provided for platforms for which we don't have binaries. |
| Q. | Does ASN1C support all syntax specified in the ASN.1 standards? |
| A. | We can parse all syntax as defined in the 1990 through 2021 standards. Equivalent C, C++, C#, or Java code is generated for most items. Please see our latest release notes for information on items currently not supported. |
| Q. | Is the the code considered to be Open Source? |
| A. | The code is not open source. However, versions of the product are available that include the run-time C and C++ source-code to allow the end-user to port their applications to a wide variety of platform types. The source code itself cannot be redistributed. |
| Q. | Does ASN1C support the old Remote Operation Support Element (ROSE) MACRO notation (OPERATION, ERROR, etc..)? |
| A. | The ASN1C compiler has a '-1990' switch that supports this notation. These keywords are not built into the standard ASN1C compiler because they are not part of the ASN.1 standard and their use might clash with other uses of the keywords. A paper describing ROSE MACRO support is available here. |
| Q. | Does ASN1C support the X.694 standard to allow ASN.1 to be generated from XML schema to produce efficient binary encodings of XML data? |
| A. |
ASN1C v6.0 and higher supports the direct compilation of XML schema definition (XSD) files. An internal translation to ASN.1 format is done in accordance with the X.694 standard. A utility program (xsd2asn1) for converting XML schema (XSD) files to equivalent ASN.1 is also included in the ASN1C distributions. |
| Q. |
It does not appear that
types/classes and encoders/decoders are generated for many
of the ASN.1 type definitions in the CAMEL Application Part
(CAP) specification. These have the following general
form:AccessPointName {PARAMETERS-BOUND: bound} ::= OCTET STRING (SIZE( bound.&minAccessPointNameLength .. bound.&maxAccessPointNameLength)) Why is this? |
| A. | These are parameterized types and code is only generated for them when a concrete instantiation is done using a supplied parameter. Unfortunately, in CAP, these instantiations are done in information objects several levels removed from where they are needed. In order to provide a way to create concrete representations of the types at the level they are defined, the -param command-line argument was added to ASN1C. For CAP, adding "-param bound=CAP-classes.cAPSpecificBoundSet" to the ASN1C command-line will provide concrete instances of all of these types. |
| Q. | When code is generated for many ASN.1 specifications, the names of some of the items are very long. Is there a way to make them shorter? |
| A. | By default, ASN1C creates names for additional types that it generates by concatanating all of the intermediate nested names of the items. In specifications with heavily nested constructs, this can lead to very long names. The -shortnames qualifier can be used in these situations to generate shorter names. |
| Q. | How can I specify different integer types for modules or productions in an ASN.1 specification? |
| A. | By default, unconstrained integer types are
32-bits wide. If a specification constrains the size of the
integer value, ASN1C will generate code that tries to use a
minimal-width type (e.g., an 8-bit type for a SIZE
(1..255) constraint). If this is undesirable,
a configuration file may be used to specify the integer
type instead. Click here for
an example configuration file. |