Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!psuvax1!rutgers!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.lang.c
Subject: Re: Programming Style
Message-ID: <15889@smoke.brl.mil>
Date: 18 Apr 91 16:30:59 GMT
References: <1991Apr16.154655.14204@hellgate.utah.edu> <28721:Apr1701:15:3791@kramden.acf.nyu.edu> <3264@borg.cs.unc.edu>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 20

In article <3264@borg.cs.unc.edu> morse@hatteras.cs.unc.edu (Bryan Morse) writes:
>The general opinion has often surfaced here that, "Well, it may be in the
>standard, but if you do it it won't be portable."  Huh???  I realize that
>it takes time for a standard to emerge and that compliance is optional,
>but does that mean we should continue to write every C program according
>to K&R Edition 1, First printing?  Never use enums, never use prototypes,
>never use voids, never return structures...

Certainly I am a proponent of C standard conformance, and some day
we may be able to rely on that for application source portability.
However, it is a fact of life that currently many C implementations
are far from standard conforming.  I've found that the implementations
I personally have to deal with fall into two categories (with small
glitches due to compiler bugs etc.):  standard conforming, or else
based on UNIX PCC.  Thus a fairly minor amount of kludgery in the
application source code can attain much wider portability of the
application than limiting it to either environment alone.  As part
of this accommodation of non-standard implementations, one often
needs to avoid assuming full ANSI C behavior of the implementation;
often this practice does not do major violence to the source code.