Path: utzoo!attcan!uunet!mcvax!cernvax!hjm
From: hjm@cernvax.UUCP (Hubert Matthews)
Newsgroups: comp.lang.c
Subject: Why trust stdio (was nasty gets(3))
Summary: If you want it done properly, do it yourself
Message-ID: <879@cernvax.UUCP>
Date: 15 Nov 88 10:38:48 GMT
Reply-To: hjm@cernvax.UUCP (Hubert Matthews)
Organization: CERN European Laboratory for Particle Physics, CH-1211 Geneva, Switzerland
Lines: 43


Why don't we avoid using any I/O routines except
read-a-char and write-a-char?  No smiley; I'm serious.  If
you want to write bomb-proof code, then you have to do all
the error handling yourself.  I don't like implementations
that barf when a number has a non-numeric character in the
middle of it.  I hate core-dumps.  In control
applications, one cannot afford to have a program that
crashes.  If I want to test a program, I turn the keyboard
upside down and bounce it a lot.  If it doesn't crash,
then it's acceptable; if it crashes, then it's broken.

The answer is to write as much of the code as possible
yourself, and use as little code provided by the
implementation as possible.  That means don't use printf,
don't use scanf AND DON'T USE GETS.  Use getc() and putc()
and that's it.  If they're broken, then you can't really
do anything useful on the machine anyway.  All the rest
can be derived from just those two - using anymore is
putting your reputation (both as a company and as a
programmer) in the hands of someone else who you don't
know whose bugs could ditch you at any time.  If I'm
programming a robot control program and I use a simple
scanf that crashes the machine because someone sneezed at
the keyboard and hit ESCAPE by mistake, who is going to
pay for the damage caused by the robot?  And what if I'm
controlling a nuclear reactor?

So, use as small a set of input/output routines as
possible, and write your own library functions to do
things properly.  Help stamp out core-dumps!  If you use
your own routines which, naturally, are written in a
portable way, then you save yourself a lot of nasty
surprises when presented with a non-user-friendly version
of stdio (for n-u-f, read broken).

(Efficiency freaks might say that doing this is slow.
Well, the library routines have to do it anyway, and
correctness is *always* more important than speed.  Error
handling never comes for free.  Ever.)
-- 

	Hubert Matthews