Path: utzoo!attcan!uunet!husc6!mailrus!nrl-cmf!cmcl2!adm!smoke!gwyn From: gwyn@smoke.BRL.MIL (Doug Gwyn ) Newsgroups: comp.lang.c Subject: Re: retiring gets(3) Message-ID: <8996@smoke.BRL.MIL> Date: 28 Nov 88 11:29:03 GMT References: <22402@watmath.waterloo.edu> <3449@geaclib.UUCP> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB)) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 49 In article <3449@geaclib.UUCP> daveb@geaclib.UUCP (David Collier-Brown) writes: > This raises the interesting, and possibly invidious, question of >why the ANSI C standard includes gets... It's there because it is useful and much existing code relies on its existence. It was specified in the library base document. There was not sufficient committee support for its removal. We've been over all this before.. >It may prove advisable to ask for its elimination on the next (NOT! >current) round of standardization, I don't know what this is intended to refer to. The proposed ANSI C standard is complete at this point and is expected to be adopted without alteration (although perhaps with additions) by ISO. The committee officially tasked with standardization did NOT deem it advisable to eliminate gets(). This is a CLOSED ISSUE insofar as the standards process is concerned. (That's why it's so annoying to me to hear it being discussed on the net as though anything was really going to, or needed to, be done about the current state of gets() in the C standard. Don't use it if you don't like it, and propagandize your friends to not use it if you wish, but stop suggesting that the standards committees deal with it. We already have. It stays.) > and a request from the (U.S) DOD Computer Security >Center (sic) for an exception in the validation suite... I don't know what model you have for how standards work. To conform to an ANSI standard, the requirements of the standard must be met. There are no provisions for "exceptions". Now, a FIPS can say anything it wants, no matter how silly, and products specified as FIPS-xxx compliant are expected to meet its requirements. An example of this is FIPS-151, which took the IEEE 1003.1 not-yet-standard (Draft 12) as its starting point then added a collection of more specific requirements to it, the result being that no planned vendor POSIX implementation was likely to meet the FIPS without the vendor's plans being revised. It is not clear that this really served anyone's interests, and it is to be hoped that in the case of C any relevant FIPS would not attempt to alter the technical requirements set forth in the ANSI standard. There is much less excuse for this with C than with POSIX, because POSIX had numerous explicit options that I suppose NBS felt obliged to nail down. What is optional in the proposed ANSI C standard are just those things that COULD NOT be made more specific without unjustifiably excluding important compilation/execution environments. There are practically NO "political options" like POSIX had. This was by design, as was the absence of "levels" of conformance and the prohibitions against name-space pollution.