Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!mimsy!umd5!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.unix.questions
Subject: Re: write (fildes, buf, nbytes) -- is "nbytes" int or unsigned?
Message-ID: <6161@brl-smoke.ARPA>
Date: Fri, 24-Jul-87 02:21:45 EDT
Article-I.D.: brl-smok.6161
Posted: Fri Jul 24 02:21:45 1987
Date-Received: Sat, 25-Jul-87 11:56:04 EDT
References: <868@bsu-cs.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) )
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 25

In article <868@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes:
>     int write (fildes, buf, nbytes)
>     int fildes;
>     char *buf;
>     unsigned nbytes;
>This is incorrect...

NO, it's correct.  What is unfortunate is that this is one of those functions
that was designed to return an error indicator "in band", so it usurped one
of the useful values from what should have been the range of return values.
This means in some implementations one has to test errno as well as the
return value, in the case that nbytes is indistinguishable from -1 when
coerced to an (int).  Usually you would only see that on a 16-bit machine
that supports 65535-byte DMA, when you request 65535 bytes.  That is a most
unlikely situation.  Somewhat more likely is the case that nbytes on a 16-bit
machine might be too large to be expressed as an (int), so one's code would
have to take that into account.

Note that the value type of the sizeof operator is unsigned, so unsigned
nbytes is a "natural" (one would never be writing a negative number of bytes).

Keep in mind that when the basic UNIX system interfaces were designed, types
were all slopped together with abandon.  It was only later that people began
to try to straighten out the type confusion, but because they were constrained
by the operation of existing systems there was only so much that they could do.