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 SmithSystem Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016