Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!husc6!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.bugs.sys5
Subject: Re: 'what' doesn't use perror to print open errors, Sys V/3.0
Message-ID: <10178@smoke.BRL.MIL>
Date: 1 May 89 03:58:33 GMT
References: <3759@sugar.hackercorp.com> <10156@smoke.BRL.MIL> <1153@aplcen.apl.jhu.edu>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 18

In article <1153@aplcen.apl.jhu.edu> bink@aplcen.apl.jhu.edu (Greg Ubben) writes:
>I regularly use perror() to report the failure of an fopen().  It works on
>all the systems I've used because, of course, the fopen() doesn't make any
>other system calls after the open().  Is this really a bad thing to do?

Yes, because there can be causes for fopen() failing that are not related
to system calls the fopen() implementation may make.  For example, suppose
there is a fixed array of FILE structures and they've all been allocated.
No system call will occur, and any perror() you do will give completely
mileading information about the problem.

By now everyone must have seen at least one report "not a typewriter"
due to a call to perror() under inappropriate circumstances.

If you have a fairly high degree of certainty that nothing could have
gone wrong that didn't involve a system call failure, then feel free to
use perror(), but you're always taking a risk when using perror() after
a non system-call library function.