Path: utzoo!attcan!uunet!mstan!frank
From: frank@Morgan.COM (Frank Wortner)
Newsgroups: comp.lang.c
Subject: Re: Why trust stdio (was nasty gets(3))
Message-ID: <115@hudson.Morgan.COM>
Date: 16 Nov 88 21:26:59 GMT
References: <879@cernvax.UUCP>
Reply-To: frank@Morgan.COM (Frank Wortner)
Organization: Morgan Stanley and Co., NY, NY
Lines: 39

In article <879@cernvax.UUCP> hjm@cernvax.UUCP (Hubert Matthews) writes:
> [...]
>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.
>
>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).

I think I'd go crazy if I had to do that.  Library writing takes
*lots* of time and effort.  I know, I designed a few compiler runtime
libraries in a previous job.  That was a full time job in itself.
Standards, even pseudo-standards like the C library, exist at least
partially to save everyone the trouble of designing *everything* from
scratch.

Of course, if we all did "roll our own," think of what would happen
if the resulting code had to be ported.  The debugging job would
include debugging the library as well as the program.

What about the compiler itself?  Can it be bug/surprise free?  I would
think that just as many implementation quirks would show up in a
compiler as in a stdio library.  I really don't want to have to write
a compiler so I can be sure of order of evaluation, side-effects,
implementation limits, etc.

Thanks, but, no thanks.

-- 
						Frank

"Computers are mistake amplifiers."