retiring gets(3)

[Doug Gwyn]

In article <3449 at geaclib.UUCP> daveb at 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.