< Back To ASN1C Support
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 comand 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 J2ME libraries for Java or C# compact edition libraries for C#. Source code can be provided for platforms for which we don't have binaries. This code can be edited to include only what is absolutely necessary to accomplish a specific encoding or decoding task (you can do this yourself or we can create a custom package for you). This will allow you to create code with the small footprint you need to fit into even the most space-constrained systems. |
| Q. | Does ASN1C support all syntax specified in the ASN.1 standards? |
| A. | We can parse all syntax as defined in the 1990 through 2015 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. | It depends on your definition of 'Open Source'. It is not in the GNU sense in which it is available for free download. But 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 platforms. |
| 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. | Why do I get the
error message LINK : fatal error LNK1104: cannot open
file 'LIBC.lib' when trying to compile samples using
Visual Studio 2005? |
| A. | This error is usually caused by trying to
link a sample program against improper libraries. The sample
programs provided with Windows packages of ASN1C use
libraries compiled with Visual Studio 6.0 by default.
Libraries for use with Visual Studio 2005 are provided in the
c_vs2005 and cpp_vs2005
directories. Copying the sample to the appropriate directory
should resolve the issue. |
| 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. |