Portability


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 architecture. Not quite so obvious is that, if shrink-wrap ANDF distribution works, the economic payoff for strictly portable applications will be greater than ever before. Of course, no one can say whether the aggregate UNIX market will ever approach the volume of the PC market. Still, many firms find it important to target both markets.

The Bad News/Opportunity

So far, this article has summarized a progression of good news, a historical trend of success at overcoming the problems of portably targeting C applications at different CPU architectures. These latest developments (a standard, a strict test suite, and a strict model implementation) make CPU-independent code a practical reality. Now for the bad news, or perhaps I should say the "opportunity." (To paraphrase Toshiro Mifune's Samurai in Yojimbo, "This looks like my kind of town.") The bad news is, most of the difficulties in producing portable applications now lie in the area of support environments, not in CPU architectures.

In the remainder of this article, I will deal with two environment issues: (1) International character sets and languages, and (2) Graphical User Interfaces (GUIs). There are several other important environment issues besides these two. (For a more detailed list, see "Portability — A No Longer Solved Problem," by Feldman and Gentleman.)

As I mentioned before, the ISO Standard for C will be official by early 1991, and identical to ANSI C. But work is progressing on a Normative Addendum that will probably add support for multi-byte (e.g., Asian) character sets. When implemented, this Addendum will allow applications to manipulate "wide chars" of 16 or more bits rather than just one-byte characters. Any locale-specific work — inputting, outputting, classifying, collating, comparing, string-handling — is all handled by the ISO Addendum library, not the application itself.

This standardization work by the ISO C working group builds upon the experience of several vendor-specific solutions. Hewlett-Packard has been building its Native Language System (NLS) since the mid-1980s. Digital Equpiment Corporation and AT&T have both added Kanji (Japanese character) support to UNIX. This means that applications can now be designed to be compiled into object code and later linked with nationality-specific libraries.

Soon, they can be semi-compiled into an ANDF, or even fully compiled and linked into executables that dynamically link with nationality-specific "shared library" modules at run time. Programs may one day adapt to nationalities and character sets that were unknown to the application designers and programmers.

This adds a new dimension, and new complications, to the generality of portable software. Many application designers may desire to avoid these complications, but the international (i.e., outside USA) marketplace is growing too fast to ignore for long.

A Portable GUI

There is also a connection between "wide char" programming and Graphic User Interfaces. A GUI is the only framework that smoothly encompasses both the single-byte European character sets and the multi-byte Asian sets. One of the major difficulties about designing portable programs for a GUI is that environments vary widely: Macintosh, Windows, Presentation Manager, Motif, Open Look, etc.

In my opinion, the most promising approach is the one taken by the Extensible Virtual Toolkit (XVT), the brainchild of Marc Rochkind. (He also developed the Source Code Control System, or SCCS, in his Bell Labs days.) XVT abstracts the common features of all these GUI environments so that your application can be written with one common GUI interface. (The interface also supports plain old character display terminals, so even anti-GUI mossbacks may find it interesting.)

The generalized model in XVT includes:

Designing a good portable interface is actually a form of object-oriented design. The purpose of the interface is to shelter the application from implementation details. This is the important design work for your portable application projects, the opportunity lurking in the bad news of the plethora of whizbang environments.

Resources

As promised, here is a summary of the resources I mentioned in this article.

Henry Rabinowitz and Chaim Schaap, Portable C, PrenticeHall, 1990.

Rex Jaeschke, Portability and the C Language, Hayden Books, 1988.

Thomas Plum, C Programming Guidelines, Plum Hall, 1989.

FlexeLint from Gimpel Software, 3207 Hogarth Lane, Collegeville PA 19426. Tel. 215-584-4261. Contact: Jim Gimpel.

C Portability Verifier from Mindcraft, 410 Cambridge Avenue, Palo Alto CA 94306. Tel. 415-323-9000. Contact: Bruce Weiner.

The ANSI C Standard, ANSI Sales Department, 1430 Broadway, New York NY 10018. Tel. 212-642-4900. Ask for X3.159-1989. Orders must be prepaid: $50 plus $6 for UPS ground shipping. No credit cards.

The ISO C Standard, ISO Committee SC22/WG14. Contact: P. J. Plauger, Convenor, 398 Main Street, Concord MA 01742. Tel. 508-369-8489.

European Compiler Testing Service, British Standards Institution, POB 375, Linford Wood, Brecklands Avenue, Milton Keynes MK14 6L0, United Kingdom. Tel. 011-44908-220-908. Contact: Neil Martin.

The Plum Hall Validation Suite for C, Plum Hall Inc., 1 Spruce Avenue, Cardiff NJ 08232. Tel. 609-927-3770. Contact: Thomas Plum.

The C Model Implementation. See European Compiler Testing Service above.

Architecture-Neutral Distribution Format (ANDF), OSF: The Open Software Foundation, 11 Cambridge Center, First Floor, Cambridge MA 02173. Contact: Sri Vasudevan.

Stuart Feldman and W. Morven Gentleman, "Portability — A No Longer Solved Problem," Computing Systems, Vol. 3, No. 2, Spring 1990, pp. 359-380.

Jim Brodie, "Extended Multibyte Support," The Journal of C Language Translation, Vol. 2, No. 2, September 1990, pp. 133-140.

David Radoff, "Toward a Global Operating Environment," CommUNIXations, Vol. 10, No. 6, August 1990, pp. 15-19.

The Extensible Virtual Toolkit, XVT from XVT Software Inc., 1800 30th Street, POB 17665, Boulder CO 80308. Tel. 303-443-4223. Contact: Marc Rochkind.