Path: utzoo!attcan!uunet!lll-winken!ames!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: lint question
Message-ID: <9418@smoke.BRL.MIL>
Date: 18 Jan 89 18:39:46 GMT
References: <491@babbage.acc.virginia.edu> <9322@smoke.BRL.MIL> <15024@cisunx.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 20

In article <15024@cisunx.UUCP> jcbst3@unix.cis.pittsburgh.edu (James C. Benz) writes:
>Okay, so where does one find out what error codes are returned from these
>stdio functions?  The UNIX (AT&T 3B2) manuals I have say nothing in printf(3S)
>about error codes, and stdio(3S) says "Individual function descriptions 
>describe the possible error conditions"  Sounds like Catch 22 to me.

I don't know what you mean by "error codes".  The printf(3S) description
in the SVR3.0 PRM clearly states that the *printf() functions return the
number of characters transmitted, or a negative number in case of error.
(Happens that the negative number is -1, but you're not supposed to know
that.)  As with all UNIX system service-related operations, if some
system call failed, the extern int "errno" is set to hold one of the
error numbers described in the introduction to section 2 of the manual.
However, library functions such as printf(3S) can fail for reasons other
than system call failure, and even a successful printf(3S) may have
generated a system call failure on the way (typically a failed ioctl(2)
invocation to determine whether the stream is associated with a terminal),
so it is unwise to rely on the contents of errno to tell you anything
meaningful about the causes of printf(3S) errors.  Just consider them
"mysterious failures" and take appropriate recovery steps.