Thoughts on multilevel standards

[Hokey]

(We have not seen any postings to mod.std.c, but since this discussion
directly relates to the standard, I am also posting to that group.  I kept
the original newsgroup in the list because that's where the original
articles were posted.)

In summary, Paul Schauble asks if the Committee has considered a multi-
level standard (K&R C, and "Full" C).  He (correctly) states that such a
standard "solves the political problem of allowing older C compilers to
be "standard" but still describes a higher level language."

John McNamee replied that such a state is not desirable:
> One thing I hope the ANSI standard will do is force vendors of C compilers
> to upgrade their products. Most microcomputer C compilers do not have enums,
> structure assignment/passing, or the void type, all of which have been
> around for some time. I hope that having an ANSI standard will push vendors
> into adding these and the other new features.

and then states:
>						  It's amazing how many bad
> compilers with very small libraries claim to be "standard" because they
> follow K&R. That makes my life harder because I have to determine on a
> case by case basis if my code will work with a given compiler. This is a big
> problem in the micro world, where many compiler writers seem to have never
> read sections 2 and 3 of the UPM.
> 
> I want to be able to move my programs to ANY compiler that follows the ANSI
> standard, not just the ones that follow subset ABC, exception XYZ. C is
> supposed to be a portable language, and having multiple levels destroys
> that portability (unless you code using the minimum language, which I dont
> want to do).

While John's first point is appropriate from the point of view of the overall
user community, there are many people who sell K&R C and, as members of the
same community, have a right to do their best to maintain their product's
viability in the marketplace.  This is also what John asks for in his last
paragraph.  The trick is to write to the minimum standard.

John's second point *may* be out of place.  Many of the library issues are
not under the control of the C standard, but of the Unix standard.  I don't
recall how the line has been drawn.

In general, there are several cases in which a multiple-level standard are
"good".  All these are primarily politically based, ranging from too many
"old" Gizmos in use, to space limitations (I want to call my Gizmo "standard"
but none of my customers want or use Module X, so we want to leave it out
of some "types" of the standard).  I can't see the space limitation being
an issue at the compiler level (yet), but the libraries do indeed fall into
this category.  Believe it or not, some folks still use 10Mbyte disks.

I am personally opposed to the Cobol approach for segregating a standard
into various levels.  The mechanism I submitted to ANSI X11.1, when these
issues were being addressed for that standard, was to have "Standard
Optional Language Extensions" (SOLE).  Under this scheme, there is a single
"low level" standard which is robust and of use to all.  This permits vendors
and users of ANSI X11.1 Mumps on machines with limited address space and
similar constraints to continue to *sell* and *buy* a product which is
easy to identify and specify.  Additional capability or functionality would
then be added either as an optional unit or incorporated into the "full"
standard.  The proposal also specified a standard way in which the existence
of SOLEs could be examined by the software, in order to facilitate the
procurement of an implementation or to help port software to an environment
in which the desired SOLEs were not present.

In C, this approach could be implemented in the preprocessor, thereby
isolating any "higher-level" functionality to an #ifdef or some such, and
also reserving space in the future for additional capabilities.

-- 
Hokey           ..ihnp4!plus5!hokey
		  314-725-9492