Chris> It *SHOULD NOT* be removed.  any program which uses gets() has
Chris> a potential bug (and, if it's a set-id program, a potential
Chris> security hole).
jtc> I disagree.  I'd like to see NetBSD become ANSI C compliant, and the
jtc> "side effect" of gets() printing a warning message makes that
jtc> impossible.

Actually, comp.std.c went around and around on this for a while, and opinion
on this was split:  implementations are free to produce spurious "diagnostic"
messages, including at runtime.  On the other hand, since the message comes
out on stderr, it alters the contents of the stderr stream.  How blessed are
diagnostics?  No one way sure.  If the message were to appear on /dev/tty,
say, or perhaps syslogged, there would be absolutely no question but that 
the standard fails to prohibit it.

jtc> I believe that Chris Torek once said (this was long ago) that he put
jtc> the warning message in gets() since there was no way to warn against
jtc> its usage at compile/link time.

Personally, the most convincing argument one way or the other is the fact
that Chris Torek said he was going to remove it :-).  (Of course, if he
didn't, it should stay. :-)


------------------------------------------------------------------------------