The purpose of this document is to describe to how to use the Abraxas Software CodeCheck Source Code Analysis System as a tool that can help move C and C++ applications from general architecture’s to LINUX architecture.

Abraxas CodeCheck was released in 1988 with the intended purpose of providing support for ‘Virtual Compilation”. That is the ability to behave as any C or C++ compiler on the market so that a developer could produce an application for any platform with out access to the target platform.

With Linux Standard Base [ LSB ] the problem of determining whether an application will port, and determining what must be modified to achieve the port can be accomplished with CodeCheck on any operating system and for any C or C++ compiler source. This means that from any computer the analysis can be accomplished, and that no matter where the C or C++ came from the analysis can be determined. The results of the analysis can be generated in any from from XML to XLS, or HTML to simple TexT. In fact CodeCheck can generate data in any forma you can imagine because it’s fully and completely programmable.

Besides being able to analyze any C or C++ from any compiler vendor for any operating system CodeCheck can detect whether the source also meets any standard. Most common standards have already implemented by CodeCheck [ SVID, POSIX, LSB, … ]. Therefore for instance its possible from Microsoft Windows 2000 to analyze MSDEV C++ and determine if it will port to LINUX POWER 64 and meet the LSB requirements and determine if the source is POSIX [ Linux LSB ] compliant and determine any 64 bit porting problems. Therefore the source can be written portable the first time and customer wanting to port from Windows 2000 can determine the complexity of the task from the source origin.

Linux Specifications cover important areas of a Linux-based system’s, including hardware support, and compatibility with other specifications - such as the Linux Standard Base (LSB), POSIX, Service Availability Forum (SA-Forum), Hardware Platform Interface (HPI).

Linux Standard Base Specification

The Linux Standard Base (LSB) defines a system interface for compiled applications and a minimal environment for support of installation scripts. Its purpose is to enable a uniform industry standard environment for high-volume applications conforming to the LSB.

The LSB defines a binary interface for application programs that are compiled and packaged for LSB-conforming implementations on many different hardware architectures. Since a binary specification must include information specific to the computer processor architecture for which it is intended, it is not possible for a single document to specify the interface for all possible LSB-conforming implementations. Therefore, the LSB is a family of specifications, rather than a single one.

The purpose of this document is to completely explain how the CodeCheck can be used to validate LSB compliant C and C++ from any source. More than just validation of course is finding the portation problems and fixing them. When a developer regularly uses CodeCheck to validate and test source portable LSB compliant source is always being generated.

Standards for the C and C++ Languages

There seem to be no fewer than six “standards” for the C and C++ language’s, all of which are covered by CodeCheck. Figure 1 depicts the family tree for C and C++ standards, with the earliest version on top:

Figure 1: The Evolution of C and C++ Standards.

Each descendent of the original C has added significant extensions to the original language, while trying to remain true to the spirit of C.

◊ The K&R standard, as described in the first edition of Kernighan & Ritchie (1978). This is certainly the single most influential book in the history of C. The language was only loosely defined in this “standard,” however, and it lacks many of the popular features that are commonplace now (e.g. enumerated constants, prototypes, the void type). Although obsolete, there are still many K&R compilers in daily use around the world.

◊ The H&S standard, as described in the first edition of Harbison & Steele (1984). This was the first careful description of the K&R standard, with many modern extensions included (e.g. the enum and void types). The H&S standard represents a transitional phase between K&R and ANSI. Most pre-ANSI compilers in use today are best described as adhering to the H&S standard.

◊ The ANSI C standard, as defined by the American National Standards Institute and certified internationally as ISO/IEC 9899. This version represented a significant advance in precision over H&S. It also introduced several significant innovations (e.g. the preprocessor paste operator).

◊ The POSIX standard, as defined by the American National Standards Institute and certified internationally as ISO/IEC 9945. Part 1 of this standard includes and extends the ANSI C standard, and details the interface and behavior of a standard library of operating system services.

◊ The C++ 2.0 standard, as defined in “The Annotated C++ Reference Manual,” by Ellis and Stroustrup (1990). This book is the base document for an ANSI committee that is now developing an official standard for C++.

◊ The C++ 3.0 standard, as defined in “The C++ Programming Language Manual, 3^rd Edition” by Bjarne Stroustrup (1997). This book is the base document of the current ANSI C++ standard.

What is CodeCheck actually doing?

So far there has not been a lot of discussion about Virtual-Compilation. When we refer to compilation we’re not referring to code generation. We referring to syntax analysis and data-base generation, the so called front-end of a C or C++ compiler.

The secret behind CodeCheck is the rule-files, they’re a C-like script that tells the CodeCheck expert-system what to do with source code after it has built a database.

A CodeCheck rule-file program looks just like a very simple C program. Indeed, CodeCheck programs are written using a small subset of the C grammar, so anyone who can read C can also read CodeCheck. A CodeCheck program is, in fact, just a collection of if-statements (called “rules”) and variable declarations. The CodeCheck interpreter translates this collection of rules into pseudo-code, which is used during the analysis of a C source to control the code checking operation.

Figure 2: Actions of the two components of CodeCheck.

To analyze a C source file, the user has only to specify the name of the C source file and the name of the CodeCheck program. The CodeCheck program will be compiled (if necessary), and then the C source file is analyzed in accordance with the CodeCheck rules. As depicted in Figure 2, CodeCheck has two logically separate components — the Code Analyzer and the Rule Compiler.

Without rule-files CodeCheck behaves just like a typical compiler. If tells you whether the source is syntactically correct or not. With a rule-file codecheck can tell you anything about the source. Given that Abraxas Software has been writing rule-files for sixteen years we honest believe that we now have rule-files for most algorithms that people might want to apply to their source. This list of course includes the ability to ask questions like?? Is this code POSIX compliant?? Is it SVID compliant?? Does it embrace the Scott Meyer’s Effective C++ writing development standards??

In summary CodeCheck is really two compilers and an expert system

1.) CodeCheck compiler “Code Analyzer” processes your input source code for emulation and builds a database.

2.) CodeCheck compiler “Rule Compiler” pre-compiles the rule-file and builds a expert system tree. Rule-Files always have the extension suffix .cc [ dot-cc ]

3.) During actual processing CodeCheck applies the rule-file expert system tree using reverse and forward chaining to the source code database. This results in the maximum amount of knowledge being extracted from any source code you wish to analyze. A “rule” in a rule-file is called an “event deferred trigger”. It’s important to know when studying codecheck rule-files that they are NOT procedural.

Of course don’t let the above scare you about performance all the three steps are done in a single pass. Since most common algorithms have already been implemented most people who use CodeCheck never have to actually learn how to write rule-files. All source for ALL rule-files are included with CodeCheck to aid in learning how to solve generic problems involving portability analysis.

Using CodeCheck without a rule-file is a lot like a “virtual-lint”. When a rule-file is applied virtually any analysis is possible. We like to differentiate two kinds of analysis Subjective and Objective. Objective would be like find all the 64 bit problems in a source file. A subjective analysis would be report back if