Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.lang.c
Subject: Re: In defense of scanf()
Message-ID: <10466@smoke.BRL.MIL>
Date: 28 Jun 89 04:36:46 GMT
References: <225800176@uxe.cso.uiuc.edu> <11831@bloom-beacon.MIT.EDU> <824@cbnewsl.ATT.COM> <1134@vsi.COM> <10397@socslgw.csl.sony.JUNET>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 40

In article <10397@socslgw.csl.sony.JUNET> diamond@csl.sony.junet (Norman Diamond) writes:
>You mean that these are design bugs instead of coding bugs.
>They are documented bugs instead of undocumented bugs.
>Just like gets() has some documented design bugs.
>Funny, existing practices that consisted of documented bugs really
>have been standardized.  Only existing practices that consisted of
>quasi-documented but necessary features have been omitted from the
>standardization.

I don't know what you mean by that last sentence.

Certainly some of the features inherited from the Base Documents
were misdesigned in the eyes of many of us, including perhaps a
majority of X3J11.  Here are the most likely alternatives that
faced the committee:
	(1) Omit the misdesigned function from the Standard.
	(2) Specify a different behavior for the function than
	    it had in existing practice, to correct the problem.
	(3) Add a newly named function with an improved design.
	(4) Standardize the function the way it actually exists.
Obviously, some of these alternatives are mutually exclusive.

It should be pretty obvious what the pros and cons are for each of
these alternatives.  Since the primary charter of X3J11 was to
standardize existing practice, when it was clear and unambiguous,
alternative (4) was used for essentially all the functions in the
Base Documents.  Alternative (3) was avoided except when there was
a pressing need, as with the localization support.  Unlike many
so-called "standardization" committees, X3J11 did not feel their
job was to design a lot of new, unproven stuff then push it as a
"standard".  Alternative (1) for the most part would have been
defaulting on the committee's primary responsibility.  Alternative
(2) would have caused major compatibility and transition problems.

I have to say that I resent the tone of your criticism.  X3J11
did an excellent job of standardizing the C programming language,
and you could have participated if you had chosen to do so.  There
were many factors that had to be carefully evaluated in arriving
at the final specification.  It is easy to imply that you could
have done better yourself, but I seriously doubt it.