Path: utzoo!utgpu!water!watmath!clyde!att!ttrdc!levy
From: levy@ttrdc.UUCP (Daniel R. Levy)
Newsgroups: comp.std.c
Subject: Re: What's a good prototype for write(2)?
Message-ID: <2991@ttrdc.UUCP>
Date: 29 Oct 88 03:27:08 GMT
References: <902@vsi.COM> <6794@pasteur.Berkeley.EDU> <21763@watmath.waterloo.edu> <8777@smoke.BRL.MIL>
Distribution: comp
Organization: AT&T, Skokie, IL
Lines: 36

In article <8777@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn ) writes:
> 
> NO!  There is no guarantee that any C data object can be written
> with a single call to write().  Don't go changing the interface
> from what it is to what you think it should have been.  Invent a
> new function instead.

I'd bet that, this being so, it's an easy error in code that uses write()
directly to do something like

	if (write(fd,(char *)&object,sizeof(object)) == -1) {
		perror(...);
		...
	} else {
		/* presume everything was hunkey dorey */
		...
	}

not taking into account the possibility of a "short write" which is yet
not the result of an error condition.  I was burned like this when porting
a game program which originally ran on System V, which to do a save writes
off its entire data segment in one big write(), to the Eunice emulation of
BSD under VMS.  write() would only work in 65k chunks, as I recall, and
I had to use a loop.

Given that write() has the "right" (no pun intended) to refuse to take the
entirety of a data object all in one shot, why isn't that exercised to solve
the problem of write() returning an int when it can be told to write an
unsigned number of bytes?  Can anyone relate any actual case histories where,
say, a 16 bit int machine wants to write off a 65k object (say, a block on a
tape)?
-- 
|------------Dan Levy------------|  THE OPINIONS EXPRESSED HEREIN ARE MINE ONLY
| Bell Labs Area 61 (R.I.P., TTY)|  AND ARE NOT TO BE IMPUTED TO AT&T.
|        Skokie, Illinois        | 
|-----Path:  att!ttbcad!levy-----|