Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!rpi!masscomp!quasar!ftw From: ftw@quasar..westford.ccur.com (Farrell Woods) Newsgroups: comp.lang.c Subject: Re: perror/strerror after fopen (was FILE *fp[];) Message-ID: <61494@masscomp.ccur.com> Date: 3 Dec 90 14:34:43 GMT References: <1990Nov27.131327.21662@agate.berkeley.edu> <14603@smoke.brl.mil> <28078@mimsy.umd.edu> <1990Nov29.164552.452@Neon.Stanford.EDU> Sender: news@masscomp.ccur.com Reply-To: ftw@westford.ccur.com (Farrell Woods) Organization: Concurrent Computer Corp. Westford MA. Lines: 26 In article <14603@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes: >Please don't do this; on UNIX, perror() will report the reason for the last >SYSTEM CALL failure, not the reason for failure of a library routine such as >fopen(). In article <28078@mimsy.umd.edu> chris@mimsy.umd.edu (Chris Torek) writes: >Some of us regard this as a bug, rather than a feature. I am not >particularly happy with the whole idea of a global `error number', >but there it is. In article <1990Nov29.164552.452@Neon.Stanford.EDU> dkeisen@Gang-of-Four.Stanford.EDU (Dave Eisen) writes: >And a surprisingly easy bug to deal with. I can't imagine writing >library code that didn't make sure errno (and other appropriate >global error numbers) were set to the most reasonable value possible. From what I've read here and elsewhere recently, errno is basically overloaded. This is especially true with anything defined in , where those functions must modify errno for certain error conditions. Bill Plauger gives an interesting discussion of this subject in the current issue of the _C Users Journal_. -- Farrell T. Woods Voice: (508) 392-2471 Concurrent Computer Corporation Domain: ftw@westford.ccur.com 1 Technology Way uucp: ...!uunet!masscomp!ftw Westford, MA 01886 "I can't drive...fifty-five!" Brought to you by Super Global Mega Corp .com