Language Extensions

There is an established ANSI C programming language standard and a more recent C++ language standard. However, much existing C and C++ software does not meet these specifications. This is partly due to software being written before the language specification was finalized (such as during the K&R phase of C), and partly due to compilers supporting extensions to the formal language.

The Imagix 4D analyzer has been developed to handle this wide range of existing code.

In many cases, this support occurs automatically. The Imagix 4D analyzer recognizes a number of historical language constructs in analyzing your software. For example, both old K&R style conditional compilation directives (#if 0) and new C++ style comments (//) are supported in analyzing C code. Also, the Imagix 4D analyzer supports a number of compiler-specific language extensions. For instance, the analyzer handles the use of the character $ in symbol names (na$me), as is allowed by certain VAX compilers and cross-compilers.

In the case of keyword extensions, you'll need to use macro definitions so that the Imagix 4D preprocessor converts the source files into appropriate C or C++ source code. For example, a number of C cross-compilers support the keywords near and far, even though they are not defined under ANSI C. In this case, you could create macro definitions that replace near and far with an empty string. This would effectively cause the Imagix 4D analyzer to ignore them in your code.

The best approach for defining these macro substitutions is to place them in the compiler configuration files. That way, you only need to define them once for each compiler you support, and modifying them becomes easier. To see some examples, refer to the .inc files in the ../imagix/user/cc_cfg directory. The files and in particular contain a number of such macro definitions.

Certain language extensions can't be defined around in this manner, and require special handling through the analyzer options, such as -gnu and -msc information (see the previous User Guide section `Analyzer Syntax and Options'). You can incorporate these options permanently into the compiler configuration files by adding the line such as "#pragma cmdflag -msc".

Inline Assembler

One language extension requiring special handling involves inline assembler code. Many compilers support the placement of assembler code in the middle of C or C++ source files. While the Imagix 4D analyzer makes no attempt to understand the inline assembler, special processing is done so that the inline assembler does not cause a problem analyzing the surrounding C or C++ code.

In part because inline assembler is not a part of the language specifications, a number of different constructs have been created for indicating that specific lines of code are inline assembler rather than C or C++. Some of these constructs are automatically handled by the Imagix 4D analyzer, in all circumstances. Other constructs, because they are potentially in conflict with other parts of the language, are supported only when particular analyzer option switches are used.

Single lines of the following formats are always skipped by the Imagix 4D analyzer:

#asm (....)
#asm <...>
#asm "..."
The following multiple line constructs are also always skipped by the analyzer:

...any number of lines...
#pragma asm
...any number of lines...
#pragma endasm
asm {
...any number of lines...
unless the -noendasm option is used, in which case:

#asm anything else on this line
is skipped, but lines between #asm and #endasm are not.

Many compilers enable the source files to contain function definitions where the body of the function is implemented in inline assembler. The commonly used format for this is:

ASM declarator_part declaration_list {
...any number of lines...
Support of these function definitions, including recognition of the declarator_part function name, is available through the -asm, -asm2, -c11, -gnu, -lnx and -msc analyzer options. The ASM keyword can be "asm" when using the -asm, -asm2 or -c11 option, "__asm" when using the -gnu or -lnx option, and "_asm" or "__asm" when using the -msc option. You can extend this keyword support through the use of macro definitions, either through -D options or via #define statements in the compiler configuration file. For example, if you used combined the option "-D_asm=asm" with the -asm option, the ASM keyword could be "_asm" as well as "asm".

There is one other common construction, supported by a number of compilers, where a block of inline assembler is used inside of a function. This is available in several formats:

ASM OPTvolatile {
...any number of lines...
ASM OPTvolatile (
...any number of lines... 

This construct is also used in a single line format, when OPTvolatile is not followed by a "{" or "(":

ASM OPTvolatile ...
The Imagix 4D analyzer support of these inline blocks of code is enabled through the same options used for the function definitions, -asm, -asm2, -c11, -gnu, -lnx and -msc. The ASM keyword represents "asm", "_asm" or "__asm", depending on the option, as described above. The OPTvolatile keyword may be "volatile" or "goto", or may be omitted.

In the single line format, the assembly code is considered to run to the end of the line. If -asm2 is used and a ";" occurs before the end of the single line, the ";" will be treated as the end of the assembly code, and the code following the ";" will be analyzed as C / C++ code.