ASN.1 to C/C++/C#/JAVA 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 is the osyslic.txt file used
in asn1rt.jar?
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. |
Our ASN.1 compilers have 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 2002 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_mscv8 and cpp_mscv8
directories. Copying the sample to the appropriate
directory should resolve the issue. |
| Q. | How is the
osyslic.txt file used in
asn1rt.jar? |
| A. | Unlike C, C++, and C#, the Java runtime
performs license checking in the runtime itself rather than
generating helper code (see rtkey.h and
*Values.cs). When a license is issued (either
at purchase time or after a hostname update, for example),
users should use the setkey.bat (Windows) or
setkey.sh (UNIX, Linux, MacOS X) script to
update the license in the JAR file. The updated JAR file
may then be copied to deployment hosts. Additional
information may be found in the ASN1C installation guide on
our documentation
page. |
| 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. |
