From owner-freebsd-hackers Wed Jan 3 14:47:09 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA23516 for hackers-outgoing; Wed, 3 Jan 1996 14:47:09 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id OAA23505 for ; Wed, 3 Jan 1996 14:47:03 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA15917 for hackers@freebsd.org; Wed, 3 Jan 1996 15:38:06 -0700 From: Terry Lambert Message-Id: <199601032238.PAA15917@phaeton.artisoft.com> Subject: OK, I'm stumped... To: hackers@freebsd.org Date: Wed, 3 Jan 1996 15:38:05 -0700 (MST) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org Precedence: bulk Why would anyone ever specify a second argument to uiomove() that was less than the largest iov->iov_len for the iov list in the uio structure that was passed in? There's a: if (cnt > (u_int)n) cnt = n; The sole purpose of which seems to cause the thing to call copyin/copyout or bcopy multiple times for a single iov. This also seems to be the sole use of the 'n' parameter to uiomove. Is there a good reason for keeping this? The sole utility seems to be in the ufs_readwrite.c code, and since the iov_len is never reexamined in these cases, couldn't it be diddled instead? Or is this a case of "rm foo" and then typing "ls" to make sure it's gone because you don't trust "rm'? Is anyone explicity using the second argument to limit the copied data from the uio struct because they didn't set the iov_len appropriately on the way in? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.