Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!wuarchive!udel!haven!adm!smoke!gwyn
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.std.c
Subject: Re: stdarg: va_list pass by value?
Message-ID: <14653@smoke.brl.mil>
Date: 4 Dec 90 21:10:11 GMT
References: <136434@pyramid.pyramid.com>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 31

In article <136434@pyramid.pyramid.com> markhall@pyrps5.pyramid.com (Mark Hall) writes:
>My personal objection is that, in the big scheme of things, there isn't
>anything available to assist the poor programmer in writing a
>"maximally portable program".  Had the standard called out a constraint
>on the operations allowable on a va_list object (my tiny little case in
>point), then I wouldn't (already!) be seeing so many non-conforming 3rd
>party programs which were not "caught" by the compiler on which they
>were developed.  Man, customers look at you funny when you tell them
>their program isn't "conforming".  They tend to suspect that XYZ's
>compiler is "better", even though your's did the harder job.  You don't
>win marketing points by having the strictest compiler around.

A deliberate decision was made to not attempt to turn the C standard
into a programming tutorial.  The examples were all supposed to simply
clarify technical points of the specification.  (There were some other
footnotes etc. added as the result of non-technical pressures, but the
resistance to doing so was pretty strong.)

There is at least one company that I know of who is marketing a "C
reference compiler" that is intended to check programs for strict
standard conformance.  Note that this is the opposite of a compiler
test suite.

The license granted implementors in the C standard is for the most
part intended to permit reasonable implementation choices to be made
for unusual environments.  Unless strict program conformance checking
is an explicit goal of your compiler product, you shouldn't use the
standard specifications as an excuse to arbitrarily reject programs
that could have been reasonably accepted; that would be contrary to
the "spirit of C", i.e. its intended use as a systems implementation
language (in addition to a platform for portable applications).