|
|
|
|
|
|
|
This option only has meaning when generating an XML schema definitions (XSD) file using the -xsd option.
It instructs the compiler to generate an XSD application information section (<appinfo>) for certain ASN.1-only items. The items are specified as a comma-delimited list. Valid values for items are tags, enum, and ext.
<items> is an optional parameter. If it is not specified, it is assumed that application information should be produced for all three item classes: ASN.1 tags, ASN.1 enumerations, and extended elements.
|
|
|
|
This option instructs the compiler to parse ASN.1 syntax conforming to the specified standard. `x680' (the default) refers to modern ASN.1 as specified in the ITU-T X.680-X.690 series of standards. `x208' refers to the now deprecated X.208 and X.209 standards. This syntax allowed the ANY construct as well as unnamed fields in SEQUENCE, SET, and CHOICE constructs. This option also allows for parsing and generation of code for ROSE OPERATION and ERROR macros and SNMP OBJECT-TYPE macros. The `mixed' option is used to specify a source file that contains modules with both X.208 and X.680 based syntax.
|
|
|
|
This option only has meaning when generating an XML schema definitions (XSD) file using the -xsd option.
It instructs the compiler to generate non-native attributes for certain ASN.1-only items that cannot be expressed in XSD. The items are specified as a comma-delimited list. Valid values for items are tags, enum, and ext.
<items> is an optional parameter. If it is not specified, it is assumed that application information should be produced for all three item classes: ASN.1 tags, ASN.1 enumerations, and extended elements.
|
|
|
|
This option instructs the compiler to generate functions that implement the Basic Encoding Rules (BER) as specified in the X.690 ASN.1 standard.
|
|
|
|
This option instructs the compiler to generate additional macros to set, clear, and test named bits in BIT STRING constructs. By default, only bit number constants are generated. Bit macros provide slightly better performance because mask values required to do the operations are computed at compile time rather than run-time.
|
|
|
|
|
|
|
|
Generate C# source code. See the ASN1C C# User's Guide for more information and options for generating C# code.
|
|
|
|
Generate C++ source code.
|
|
|
|
This option instructs the compiler to generate functions that implement the Canonical Encoding Rules (CER) as specified in the X.690 ASN.1 standard.
|
|
|
|
This option allows the specification of a C or C++ source (.c or .cpp) file to which all of the generated encode/decode functions will be written. If not specified, the default is to write to a series of .c or .cpp files based on the ASN.1 module name(s) of the documents being compiled.
|
|
|
|
This option instructs the compiler to generate more compact code
at the expense of some constraint and error checking. This is an optimization option that should be used after an application is thoroughly tested.
|
|
|
|
Generate code compatible with an older version of the compiler. The compiler will attempt to generate code more closely aligned with the given previous release of the compiler.
<versionNumber> is specified as x.x (for example, -compat 5.2)
|
|
|
|
This option is used to specify the name of a file containing configuration information for the source file being parsed. A full discussion of the contents of a configuration file is provided in the Compiler Configuration File section.
|
|
|
|
This option instructs the compiler to generate a full set of header and source files that contain only the productions in the main file being compiled and items those productions depend on from IMPORT files.
|
|
|
|
This option instructs the compiler to generate functions that implement the Distinguished Encoding Rules (DER) as specified in the X.690 ASN.1 standard.
|
|
|
|
When used in conjunction with the -genMake command-line option, the generated makefile uses dynamically-linked libraries (DLLs in Windows, or .so files in UNIX) instead of statically-linked libraries.
|
|
|
|
Selecting this option instructs the compiler to generate test functions that populate data structures with data from XML documents. The generated functions use the libxml2 DOM-parsing code to construct a DOM-tree and then populate the structures with data from that tree.
The <filename> argument to this option is optional. If not specified, the functions will be written to <modulename>Test.c where <modulename> is the name of the module from the ASN.1 source file.
|
|
|
|
Generate extra code to invoke user defined event and error handler callback methods (see the Event Handlers section). When combined with the -notypes option, causes pure parser functions to be generated.
|
|
|
|
This option instructs the compiler to generate a build script when producing Java source code. The generated build script is either a batch file (Windows) or a shell script (UNIX).
|
|
|
|
This option allows the specification of a C or C++ source (.c or .cpp) file to which generated compare functions will be written. Compare functions allow two variables of a given ASN.1 type to be compared for equality.
The <filename> argument to this option is optional. If not specified, the functions will be written to <modulename>Compare.c where <modulename> is the name of the module from the ASN.1 source file.
|
|
|
|
This option allows the specification of a C or C++ source (.c or .cpp) file to which generated copy functions will be written. Copy functions allow a copy to be made of an ASN1C generated variable. For C++, they cause copy constructors and assignment operators to be added to generated classes.
The <filename> argument to this option is optional. If not specified, the functions will be written to <modulename>Copy.c where <modulename> is the name of the module from the ASN.1 source file.
|
|
|
|
This option instructs the compiler to generate a memory free function for each ASN.1 production. Normally, memory is freed within ASN1C by using the rtMemFree run-time function to free all memory at once that is held by a context. Generated free functions allow finer grained control over memory freeing by just allowing the memory held for specific objects to be freed.
|
|
|
|
This option instructs the compiler to generate a portable makefile for compiling the generated C or C++ code. If used with the -w32 command-line option, a makefile that is compatible with the Microsoft Visual Studio nmake utility is generated; otherwise, a GNU-compatible makefile is generated.
|
|
|
|
This option allows the specification of a C or C++ source (.c or .cpp) file to which generated print functions will be written. Print functions are debug functions that allow the contents of generated type variables to be written to stdout.
The <filename> argument to this option is optional. If not specified, the print functions will be written to <modulename>Print.c where <modulename> is the name of the module from the ASN.1 source file.
|
|
|
|
This option allows the specification of a C or C++ source (.c or .cpp) file to which generated "print-to-string" functions will be written. "Print-to-string" functions are similar to print functions except that the output is written to a user-provided text buffer instead of stdout. This makes it possible for the use to display the results on different output devices (for example, in a text window).
The <filename> argument to this option is optional. If not specified, the functions will be written to <modulename>Print.c where <modulename> is the name of the module from the ASN.1 source file.
|
|
|
|
This option allows the specification of a C or C++ source (.c or .cpp) file to which generated "print-to-stream" functions will be written. "Print-to-stream" functions are similar to print functions except that the output is written to a user-provided stream instead of stdout. The stream is in the form of an output callback function that can be set within the run-time context making it possible to redirect output to any type of device.
The <filename> argument to this option is optional. If not specified, the functions will be written to <modulename>Print.c where <modulename> is the name of the module from the ASN.1 source file.
|
|
|
|
This option is used to generate additional code for the handling of table constraints as defined in the X.682 standard. See the Generated Information Object Table Structures section for additional details on the type of code generated to support table constraints.
|
|
|
|
This option allows the specification of a C or C++ source (.c or .cpp) file to which generated "test" functions will be written. "Test" functions are used to populate an instance of a generated PDU type variable with random test data. This instance can then be used in an encode function call to test the encoder. Another advantage of these functions is that they can act as templates for writing your own population functions.
The <filename> argument to this option is optional. If not specified, the functions will be written to <modulename>Test.c where <modulename> is the name of the module from the ASN.1 source file.
|
|
|
|
This option allows the specification of a header (.h) file
to which all of the generated typedefs and function prototypes will be written. If not specified, the default is <modulename>.h where <modulename> is the name of the module from the ASN.1 source file.
|
|
|
|
This option is used to specify a directory that the compiler will search for ASN.1 source files for IMPORT items. Multiple -I qualifiers can be used to specify multiple directories to search.
|
|
|
|
Generate Java source code. See the ASN1C Java User's Guide for more information on Java code generation.
|
|
|
|
This option instructs the compiler to not generate code to check constraints. When used in conjunction with the -compact option, it produces the smallest code base for a given ASN.1 specification.
|
|
|
|
Generate listing. This will dump the source code to the standard output device as it is parsed. This can be useful for finding parse errors .
|
|
|
|
Maximize number of generated C files. This option instructs the compiler to generate a separate .c file for each generated C function. In the case of C++, a separate .cpp file is generated for each control class, type, and C function. This is a space optimization option - it can lead to smaller executable sizes by allowing the linker to only link in the required program module object files.
|
|
|
|
This option is used to specify the maximum number of lines per generated .c or .cpp file. If this number is exceeded, a new file is started with a "_n" suffix where "n" is a sequential number. The default value if not specified is 50,000 lines which will prevent the VC++ "Maximum line numbers exceeded" warning that is common when compiling large ASN.1 source files.
Note that this number is approximate - the next file will not be started until this number is exceeded and the compilation unit that is currently being generated is complete.
|
|
|
|
When used in conjunction with the -genMake command-line option, the generated makefile uses multi-threaded libraries.
|
|
|
|
This option suppresses the generation of decode functions.
|
|
|
|
This option suppresses the generation of encode functions.
|
|
|
|
This option instructs the compiler to omit indefinite length tests in generated decode functions. These tests result in the generation of a large amount of code. If you know that your application only uses definite length encoding, this option can result in a much smaller code base size.
|
|
|
|
This option instructs the compiler not to generate an initialization function for each ASN.1 production. A variable of a generated structure can always be initialized by memset'ing the variable to zero. However, this is not usually the most efficient way to initialize a variable because if it contains large byte arrays, a significant amount of processing is required to set all bytes to zero (and they don't need to be). Initialization functions provide a smart alternative to memset'ing in that only what needs to be set to zero actually is.
Note that previous versions of the compiler did not generate initialization functions by default. The -genInit switch has been deprecated in favor of -noInit.
|
|
|
|
This option suppresses the generation of application language types corresponding to ASN.1 types embedded within information object definitions.
|
|
|
|
This option instructs the compiler to not add an open extension element ( extElem1) in constructs that contain extensibility markers. The purpose of the element is to collect any unknown items in a message. If an application does not care about these unknown items, it can use this option to reduce the size of the generated code.
|
|
|
|
This options suppresses the generation of type definitions. It is used in conjunction with the -events options to generate pure parser functions.
|
|
|
|
This option instructs the compiler not to automatically generate unique names to resolve name collisions in the generated code. Name collisions can occur, for example, if two modules are being compiled that contain a production with the same name. A un ique name is generated by prepending the module name to one of the productions to form a name of the form <module>_<name>.
Note that name collisions can also be manually resolved by using the typePrefix, enumPrefix, and valuePrefix configuration items (see the Compiler Configuration File section for more details).
Previous versions of the compiler did not generate unique names by default. The compiler option -uniquenames has been deprecated in favor of -nouniquenames.
|
|
|
|
This option is used to specify the name of a directory to which all of the generated files will be written.
|
|
|
|
This option is used to specify the name of a directory to which only the generated header files (*.h) will be written.
|
|
|
|
This option is used to instantiate all parameterized types with the ASN.1 modules that are being compiled with the given parameter value. In this declaration, <name> refers to the dummy reference in a parameterized type definition and <value> refers to an actual value.
|
|
|
|
Designate given type name to be a "Protocol Definition Unit" (PDU) type. This will cause a C++ control class to be generated for the given type. By default, PDU types are determined to be types that are not referenced by any other types within a module. This option allows that behavior to be overridden.
The `*' wildcard character may be specified for <typeName> to indicate that all productions within an ASN.1 module should be treated as PDU types.
|
|
|
|
This option instructs the compiler to generate functions that implement the Packed Encoding Rules (PER) as specified in the ASN.1 standards.
|
|
|
|
Sets the print format for generated print functions. The details option causes a line-by-line display of all generated fields in a generated structure to be printed. The bracetext option causes a more concise printout showing only the relevant fields in a C-like brace format. As of release version 6.0, bractext is the default ( details was the default or only option in previous versions).
|
|
|
|
Generate a shorter form of an element name for a deeply nested production. By default, all intermediate names are used to form names for elements in nested types. This can lead to very long names for deeply nested types. This option causes only the production name and the last element name to be used to form a generated type name.
|
|
|
|
This has the same effect as specifying the global <storage> static
</storage> configuration item. The compiler will insert static elements instead of pointer variables in some generated structures.
|
|
|
|
This option instructs the compiler to generate stream-based encoders/decoders instead of memory buffer based. This makes it possible to encode directly to or decode directly from a source or sink such as a file or socket. In the case of BER, it will also cause forward encoders to be generated, which will use indefinite lengths for all constructed elements in a message.
Note that stream and memory-buffer based encode/decode functions cannot be used/combined in any way. The two are mutually exclusive. If the -stream option is selected, then only stream-based run-time functions can be used with the generated code.
|
|
|
|
This option instructs the compiler to generate code for strict validation of table constraints. By default, generated code will not check for value field constraints.
It should be noted that real world messages typically do not strictly follow value field table constraint definitions. Therefore, this option should be used with care.
|
|
|
|
This option only has meaning when generating an XML schema definitions (XSD) file using the -xsd option.
It allows specification of a target namespace. <namespace> is a namespace URI; if it is not provided, no target namespace declaration is added to the generated XSD file.
|
|
|
|
This option is used to tell the compiler to add trace diagnostic messages to the generated code. These messages cause print statements to be added to the generated code to print entry and exit information into the generated functions. This is a debugging option that allows encode/decode problems to be isolated to a given production processing function. Once the code is debugged, this option should not be used as it adversely affects performance.
|
|
|
|
This option instructs the compiler to generate Visual C++ 6.0-compatible project files to compile generated source code. This is a Windows-only option.
|
|
|
|
Output information on compiler generated warnings.
|
|
|
|
|