Introduction:

COHERENT comes with a good K&R C compiler, that also supports some ANSI standard features. What it does not support are ANSI prototypes, which was usual for UNIX C compilers in the early 90th. This won't be really a problem, because one always can formulate:




			#ifndef __STDC__
			  int main(argc, argv)
			  int argc;
			  char *argv;
			#else
			  int main(int argc, char *argv)
			#endif

With this sources would compile with K&R as well as with ANSI C compilers, of course it often wasn't done, and modifying large C projects can become tedious.

Fortunatly this process can easily be automated, Wietse Venema wrote an unprotoize filter for this in 1993, that sits in between the UNIX C preprocessor and the next compiler stage. The MWC C compiler won't use a separate ccp, but the FSF already offered GNU cpp. So I build a package 'ansicc' from unproto, GNU cpp and a shell script driver, feeding MWC cc with the filtered source.

So instead of invoking cc one uses ansicc to compile ANSI C source with the MWC compiler. While this fixes the compilation issue, the prototypes are not checked and one still would need lint for locating questionable programming.

The ansicc package is installed on the VM's from here, so that this ancient technique still can be tried and tested.

GNU compilers:

Needs to be written.

Compilation Environments and Feature Tests:

The following was written by MWC documentation guru Fred Butzen. I can't write it any better, so I'm using Fred's text here.

The COHERENT header files are designed to let you invoke any of several ``compilation environments''. Each environment offers its own features; in this way, you can easily import code that conforms to the POSIX or ANSI standards, compile device drivers, or otherwise fine tune how your programs are compiled. To invoke a given compilation environment, you must set a feature test.

As discussed in the Lexicon article name space, the ISO Standard reserves for the implementation every identifier that begins with a single underscore followed by an upper-case letter. The POSIX Standards define several symbols in this name space that the implementation can use as ``feature tests'' -- that is, as symbols that you can use in your source code to determine the presence or absence of a particular feature or combination of features. Note that a feature test applies to an implementation of C, rather than to an operating system. A feature test combines aspects of the host system and the language translator: some tests apply to the operating system, some purely to the C translator.

The operating system's header files can define them (for example, _POSIX_SAVED_IDS) to control compilation of user code or to deal with optional features, or you can define them (e.g., _POSIX_C_SOURCE) to control how the system's header files declare or define constants, types, structures, and macros.

In general, a feature test must either be undefined or have an integer value. It must not be defined as having no expansion text, or expand into a string. For example,

	# CORRECT
	cc -D_POSIX_C_SOURCE=1 foo.c
is correct, as is:
	# CORRECT
	cc -U_POSIX_C_SOURCE foo.c
However,
	# WRONG
	cc -D_POSIX_C_SOURCE foo.c
is incorrect, as is:
	# WRONG
	cc -D_POSIX_C_SOURCE="yes" foo.c
This is to permit the constants to be tested with expressions like
	#if _POSIX_C_SOURCE > 1
where an integer value is required. (If the symbol is used in a #if test and is undefined, cpp replaces it with zero, which is still an integer value). This permits the implementation to use different values of the feature test to invoke different feature sets; and it simplifies testing for complex combinations of feature tests.

Although nearly all feature tests behave as shown above, there are a few exceptions, namely _POSIX_SOURCE and _KERNEL. These symbols are not defined as having a specific value, so many users do not supply a value. To deal with this, the COHERENT header files check whether these constants have expansion text. If they do not, the header files redefine these constants with value 1, so that they can be used like the other feature tests that the COHERENT header files define.

The following describes the feature tests used in the COHERENT header files, and briefly describes the compilation environment each invokes. Because we are continually adding new features to the kernel, this list is not guaranteed to be complete.

_DDI_DKI
Invoke the environment for compiling device drivers. This environment makes visible all DDI/DKI function prototypes and data definitions, and defines all fundamental data types and structures as mandated by UNIX System V, Release 4.
Please note that this feature test is an COHERENT extension, and is not portable to other operating systems.

_KERNEL
Invoke the environment for compiling the kernel or a device driver. This environment gives code full access to system's private header files. Under COHERENT, this option is equivalent to defining _DDI_DKI to value 1, because COHERENT only supports compiling DDI/DKI driver source code from System V, Release 4. This means that the definitions of many fundamental data types such as pid_t are changed to the System V, Release 4 definitions rather than the System V, Release 3 definitions used by user code. (This is a System V convention.)

_POSIX_SOURCE
_POSIX_C_SOURCE
Select a ``clean'' compilation environment, in which the headers defined in the POSIX.1 or POSIX.2 standards define no symbols other than the ones that those environments require. Defining _POSIX_C_SOURCE with value 1 selects the POSIX.1 environment, as defined in the POSIX.1 standard. Defining _POSIX_C_SOURCE with value 2 selects the POSIX.2 environment, as defined in the POSIX.2 standard. Defining _POSIX_SOURCE has the same effect as defining _POSIX_C_SOURCE with value 1.

_STDC_SOURCE
Select a ``clean'' compilation environment. In this environment, the headers that the ANSI C standard defines define no symbols other than those that the standard requires. This feature test is designed to let you compile conforming Standard C programs that themselves define functions or macros that the COHERENT header files defined in addition to those described in the ANSI standard.
Please note that this feature test is an COHERENT extension, and is not portable to other operating systems.

_SUPPRESS_BSD_DEFINITIONS
This feature test invokes a compilation environment that excludes all definitions that are included for compatibility with Berkeley UNIX. As of this writing, this feature test affects only the header file , and prevents it from defining the macros bcopy(), bzero(), index(), and rindex(). Note that selecting a POSIX or Standard C environment also suppresses these definitions.
Please note that this feature test is an COHERENT extension, and is not portable to other operating systems.

_SYSV3
This feature test invokes a compilation environment in which all fundamental types and data structures have the definitions mandated by UNIX System V, Release 3.

_SYSV4
This feature test invokes a compilation environment in which all fundamental types and data structures have the definitions mandated by UNIX System V, Release 4. As of this writing, this facility is incomplete and used mainly to develop device drivers and extensions to the kernel.
Please note that this feature test is an COHERENT extension, and is not portable to other operating systems.