Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!adm!dsill@NSWC-OAS.arpa
From: dsill@NSWC-OAS.arpa (Dave Sill)
Newsgroups: comp.lang.c
Subject: Re: stdio error detection
Message-ID: <10649@brl-adm.ARPA>
Date: Thu, 3-Dec-87 12:40:50 EST
Article-I.D.: brl-adm.10649
Posted: Thu Dec  3 12:40:50 1987
Date-Received: Mon, 7-Dec-87 02:37:24 EST
Sender: news@brl-adm.ARPA
Lines: 46

In article <336@cresswell.quintus.UUCP>, Richard O'Keefe  writes:

	[library functions should set errno on error]

I've always thought there should be more attention paid to libraries,
they're such an important part of the language.  It's almost common
knowledge that FORTRAN floating point libraries are superior to those
found with C compilers.  This is understandable, given that FORTRAN is
used almost exclusively for scientific computations.  So it should
follow, then, that C's libraries, being for a "systems programming"
language would be adept at handling errors.

Unfortunately, they're not.  The defacto level of error detection is a
binary flag; a function can say either "here's the result, everything
worked" or "oops, something's wrong, that didn't work".  I don't know
how much the dpANS says about library functions, but I can understand
why X3J11 wouldn't want to touch this with a ten-foot can opener.  It
might have been more in line with the POSIX standard to change the
behavior of standard library functions, but it still would have
required breaking new ground, i.e., there is none of the "prior art"
that standards groups like so much.

>I used to be rather fond of C, but this error stuff is quite
>incredibly bad.  The problem isn't really the language; it's
>the libraries.

I agree, but come to think of it, I don't know of a language with
error handling significantly better.  BASIC?  FORTRAN?  Pascal?  When
a file `open' or `close' fails, can you find out why?

Rather than messing with errno, I think a new variable, say, liberr,
should be used.  An include file, say liberr.h, could contain macro
definitions for the various types of errors.  A macro named LIBERR
could also be defined in liberr.h so code could be written that would
take advantage of liberr if it was available or handle errors in the
usual way if it's not.  Even better would be to have LIBERR be a
predefined macro like ANSI, unix, vax, et cetera.

There might be a better way.  Any ideas?

----
These are my personal opinions.
----

"Don't let existing sub-optimal solutions cloud your vision."
			-- Fred Fish