From owner-cvs-all Sat Dec 28 21:19:49 2002 Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C76B937B406; Sat, 28 Dec 2002 21:19:47 -0800 (PST) Received: from thuvia.demon.co.uk (thuvia.demon.co.uk [193.237.34.248]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5166B43ED4; Sat, 28 Dec 2002 21:19:43 -0800 (PST) (envelope-from mark@thuvia.demon.co.uk) Received: from dotar.thuvia.org (dotar.thuvia.org [10.0.0.4]) by phaidor.thuvia.org (8.12.3/8.12.3) with ESMTP id gBT5JVcF075479; Sun, 29 Dec 2002 05:19:33 GMT (envelope-from mark@thuvia.demon.co.uk) Received: from dotar.thuvia.org (localhost [IPv6:::1]) by dotar.thuvia.org (8.12.6/8.12.6) with ESMTP id gBT5JVH5019639; Sun, 29 Dec 2002 05:19:31 GMT (envelope-from mark@dotar.thuvia.org) Received: (from mark@localhost) by dotar.thuvia.org (8.12.6/8.12.6/Submit) id gBT5JVeN019638; Sun, 29 Dec 2002 05:19:31 GMT Date: Sun, 29 Dec 2002 05:19:31 GMT From: Mark Valentine Message-Id: <200212290519.gBT5JVeN019638@dotar.thuvia.org> In-Reply-To: <20021229145941.G39748-100000@gamplex.bde.org> X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Bruce Evans Subject: Re: cvs commit: src/sys/sys _iovec.h socket.h uio.h Cc: Poul-Henning Kamp , , Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > From: Bruce Evans > Date: Sun 29 Dec, 2002 > Subject: Re: cvs commit: src/sys/sys _iovec.h socket.h uio.h > On Sun, 29 Dec 2002, Mark Valentine wrote: > > Actually, the IEEE Std 1003.1-2001 spec. for states: > > > > "Inclusion of may also make visible all symbols > > from ." > > > > So, it seems it would be sufficient to have a single definition of > > struct iovec in . > > Only low quality implementations would use this mistake. Ah. I read it as an implementation hint, but it is a bit inconsistent with what I'm used to with POSIX standards. > This is simpler for > implementations but more difficult for applications -- applications > have to be concerned about namespace pollution in every standard header > but can't depend on it. Indeed, an application can't depend on seeing a prototype for writev() due to including . However, given that the standard says that it _may_, in this case I still don't see why such an implementation would be so poor, other than forcing the compiler to parse the pollution of readv()/ writev() declarations for applications which include (which I guess is reason enough to some). > > It would seem to also work having it in , since both > > interfaces from and some from use ssize_t > > and/or size_t, but this should be considered accidental. > > It would work as well as declaring FILE in and including > that in (not). Urk, I wasn't advocating including in either or , simply pointing out that an application using either of the last two will also be including the first. Nor was I even implying that this would be anything other than a poor implementation. Cheers, Mark. -- Mark Valentine, Thuvia Labs "Tigers will do ANYTHING for a tuna fish sandwich." Mark Valentine uses "We're kind of stupid that way." *munch* *munch* and endorses FreeBSD -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message