home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
C/C++ Users Journal 1990 - 1995
/
CUJ.iso
/
mac
/
1991.txt
< prev
next >
Wrap
Text File
|
1996-02-07
|
3MB
|
99,905 lines
Resources For Portable C Applications
Thomas Plum
Dr. Thomas Plum is President of Plum Hall Inc., a training firm that also
supplies the leading ANSI C validation suite. Dr. Plum serves as Vice Chair of
ANSI X3J11, the committee that developed the C standard.
Let me begin with a bald assertion. Bald Assertion #1: As of 1991, a C source
file should be either (a) written in non-portable ANSI/ISO Standard C for a
specific environment (e.g. a device driver), or (b) written in strictly
portable Standard C suitable for compilation and execution in any environment
whatsoever. There is no justification for intermediate levels of "somewhat
portable" code.
This wasn't what I set out to write about, but it is the inescapable
conclusion given current resources and projects. In this article, I will
describe some of the resources that are likely to be important for your work
on portable C projects. Contact address information is available at the end of
the article.
Books On Portability
There are two comprehensive survey books on the line-by-line portability
coding issues: Portable C, by Rabinowitz and Schaap, and Portability and the C
Language, by Jaeschke. (See Resources at the end of this article.) Rabinowitz
and Schaap's book traces its origins back to a seminar that Schaap and I wrote
for Bell Labs in 1980. At the time Schaap was the first consultant for the
fledgling Plum Hall Inc. The work has grown into a wealth of detail. It is
very accurate information. The Jaeschke book is also extremely authoritative.
A project leader responsible for portability should probably read both books.
Nevertheless, both books have a point of view that I quarrel with. Besides the
current C Standard, they cover multiple flavors of "old C" in great detail.
These dozens (or hundreds?) of pages on "old C problems" are in themselves a
convincing reason to stick to strict Standard C. The world could use a
"Standard-only" version of each book. Aside from this, both books are a
valuable condensation of practical advice from years of project experience.
Also in the category of collected hints from prior experience is Plum Hall's
own book, C Programming Guidelines, ("CPG," now in Second Edition for Standard
C). Presented in the form of a project coding standard, CPG contains
suggestions on data types, operators, and library functions for portable
coding. CPG is available in an inexpensive machine-readable format to serve as
the starting point for each project's own coding standard.
The fundamental portability resource is, of course, the ANSI C Standard
itself. It represents seven years of work by hundreds of C experts. The
corresponding ISO Standard is expected to be official by the end of 1990,
identical in every way but typographic layout.
Portability Testing Software
Another condensation of practical experience is the FlexeLint tool from Gimpel
Software. This is a compile-time syntax analyzer that monitors adherence both
to Standard C and to a large collection of portability-enhancing coding
restrictions. For years, Gimpel has had an active customer base suggesting
(and demanding) practical compile-time tests for portability. FlexeLint
scrutinizes for portability problems involving the signedness of char,
variations in character sets, sizes of integers, pointer casts, declarations
and linkage, called-function vs. calling-function discrepancies, etc.
I am especially fond of FlexeLint's ability to selectively disable specific
tests. When it comes to heuristic coding rules, no two projects agree
completely. I've used FlexeLint on several Plum Hall projects, and it works
well.
Similar capabilities are described for the C Portability Verifier from
Mindcraft, but I haven't been able to test it yet.
Because the ANSI C Standard is the only official Standard for C, I suggest
another bald assertion. Bald Assertion #2: Any organization that cares about
portable C will insist that its procurements require certified
Standard-conforming compilers.
Vendors who want to sell compilers to your project can obtain this
certification from the European Compiler Testing Service (ECTS). This body
includes the British Standards Institution (UK), AFNOR (France), and IMQ
(Italy). (The US government standards agency, NIST, plans a different
approach, probably available late 1991 or early 1992. More on this in another
article.) ECTS uses the Plum Hall Validation Suite for C as its criterion for
certification.
I'll stake my professional reputation on this claim: If your compiler vendor
truthfully claims to conform to the C Standard, then that vendor's product can
pass the Plum Hall Suite and get officially certified. You do not have to rely
upon advertising claims in your procurements. If customers insist upon
Standard-conforming compilers, vendors will provide them. Several vendors
already have been fully certified by ECTS. There are dozens of others who
could get certified if customers demanded it.
The Standard is central to the subject of C portability because it is the
"treaty" between compiler vendors and programming projects. It defines exactly
what capabilities the portable C program can expect from every environment.
A Model Implementation
The strictness of this treaty makes possible a new form of portability-testing
tool. It is one that enforces every detailed requirement that the Standard
imposes upon an application program. Such a tool is the C Model
Implementation, commissioned and distributed by the British Standards
Institution and produced by Knowledge Software Ltd.
Basically, the C Model is an extremely fussy C implementation that
syntax-checks your application for every compile-time requirement of the
Standard. It also generates a form of intermediate p-code, runs the p-code
through an equally fussy linker, then executes the program with diagnosis of
every runtime "undefined behavior." The net result is that, if your program
compiles and runs clean under the C Model, and you then compile and run it on
an environment that conforms faithfully to the Standard, the program will
compile and run clean there, too.
Thus, the C Model is an interesting departure from the item-by-item
accumulation of heuristics that characterized the previous resources
(including my own C Programming Guidelines). It was produced, test-by-test,
directly from the Standard itself.
During this past year, the C Model has found more subtle non-portabilities in
our Plum Hall Suite than did all the specific hardware environments. It
demonstrates to its users that strictly portable C takes some discipline to
produce, but also that it can be done.
Shrink-Wrapped C
Closely related in concept to the C Model is the Architecture-Neutral
Distribution Format (ANDF) project of the Open Software Foundation (OSF). The
goal here is to distribute "shrink-wrapped" applications that can be run
without modification on any suitable target system. One industry standard
assumed by ANDF is ANSI/ISO Standard C (as verified by the Plum Hall Suite).
Another is the OSF/1 version of the UNIX operating system, which in turn is
specified to meet the IEEE 1003 (POSIX) standard and the X/Open UNIX
portability standard. OSF is currently conducting a competition (now down to
four finalists) for a technology that will allow applications to be
distributed in a "semi-compiled" form. Actual machine-specific code generation
is postponed until the end-user performs the "install" process.
Obviously, an application intended for shrink-wrap distribution must be
totally free from dependencies upon the specific target architectu