perror/strerror after fopen (was FILE *fp[];)

[Farrell Woods]

In article <14603 at smoke.brl.mil> gwyn at 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 at mimsy.umd.edu> chris at 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 at Neon.Stanford.EDU> dkeisen at 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 <math.h>,
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 at westford.ccur.com
1 Technology Way				uucp:  ...!uunet!masscomp!ftw
Westford, MA 01886				"I can't drive...fifty-five!"