Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site phri.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!lll-crg!dual!qantel!ihnp4!drutx!mtuxo!mtunh!mtung!mtunf!ariel!vax135!timeinc!phri!roy
From: roy@phri.UUCP (Roy Smith)
Newsgroups: net.lang.c
Subject: Re: casts to (void) [in particular, (void) printf (...)]
Message-ID: <386@phri.UUCP>
Date: Thu, 8-Aug-85 16:20:04 EDT
Article-I.D.: phri.386
Posted: Thu Aug  8 16:20:04 1985
Date-Received: Tue, 13-Aug-85 01:09:02 EDT
References: <11@brl-tgr.ARPA> <1288@eagle.UUCP> <15908@watmath.UUCP>
Organization: Public Health Research Inst. (NY, NY)
Lines: 20
Keywords: printf, error status

[ assorted babble about (void) hiding printf(3S) errors leading to the
observation that printf doesn't return any kind of error status]

> [...] printf(3) calls the system call write(2).  If sucessful, the return
> value is set to the number of characters written, else -1 is returned and
> errno is set to describe the error.

	Not quite.  Printf(3) calls putc(3) which (on most implementations)
is a macro which calls _flsbuf() (or something similar) when an internal
buffer gets full, which in turn eventually calls write(2).  The point is
that write(2) doesn't get called on every invocation of printf, so when
printf returns, the write errors have not yet happened.

	This behaviour is documented in the 4.2 manual page for putc, but
not in the Sys5 manual.  In either case, if you want to check for write
errors, printf is not the way to go.
-- 
Roy Smith 
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016