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.