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'Keefewrites: [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