From owner-freebsd-current Tue Nov 5 17:33:56 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F1DD937B401; Tue, 5 Nov 2002 17:33:53 -0800 (PST) Received: from kayak.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 90DA943E42; Tue, 5 Nov 2002 17:33:52 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from athlon.pn.xcllnt.net (athlon.pn.xcllnt.net [192.168.4.3]) by kayak.xcllnt.net (8.12.6/8.12.6) with ESMTP id gA61Xk0N000863; Tue, 5 Nov 2002 17:33:46 -0800 (PST) (envelope-from marcel@kayak.pn.xcllnt.net) Received: from athlon.pn.xcllnt.net (localhost [127.0.0.1]) by athlon.pn.xcllnt.net (8.12.6/8.12.6) with ESMTP id gA61XjFM001726; Tue, 5 Nov 2002 17:33:45 -0800 (PST) (envelope-from marcel@athlon.pn.xcllnt.net) Received: (from marcel@localhost) by athlon.pn.xcllnt.net (8.12.6/8.12.6/Submit) id gA61XjFk001725; Tue, 5 Nov 2002 17:33:45 -0800 (PST) (envelope-from marcel) Date: Tue, 5 Nov 2002 17:33:45 -0800 From: Marcel Moolenaar To: Maxime Henrion Cc: Juli Mallett , Patrick Hartling , current@freebsd.org Subject: Re: uuid.h is not C++ safe Message-ID: <20021106013345.GA1633@athlon.pn.xcllnt.net> References: <3DC71B56.1050102@137.org> <20021105105813.GD26605@elvis.mu.org> <20021105105927.GE26605@elvis.mu.org> <20021105030419.A19427@FreeBSD.org> <20021105111724.GF26605@elvis.mu.org> <20021105123036.A99916@kayak.xcllnt.net> <20021105234624.GI26605@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021105234624.GI26605@elvis.mu.org> User-Agent: Mutt/1.5.1i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Nov 05, 2002 at 03:46:24PM -0800, Maxime Henrion wrote: [snip] > > > That's arguably bad, sys/uuid.h shouldn't have any !_KERNEL prototypes > > > in it. > > > > If there's a better place, then we should move it. We could put it in > > , but I don't want to make that header a requirement if one > > only uses the syscall. I don't yet know what a good place would be, > > if not . Suggestions? > > Well I don't really understand what you mean here. I'm not sure I like uuidgen(2) in . is the DCE 1.1 compliant interface to UUIDs. describes the underlying generic interface on which builds. It feels wrong to mix them... > Since this prototype > is #ifndef _KERNEL in sys/sys/uuid.h and since this header is included by > lib/libc/uuid/uuid.h, moving it into the libc header shouldn't make any > difference both in visibility and header requirements. There is no difference when was included already. There is a difference when only was included before. One cannot use uuidgen(2) without also including the DCE 1.1 compliant stuff. Does the interface seperation make sense or can it be categorized as some sort of obscene fetish? :-) > Index: lib/libc/uuid/uuid.h > =================================================================== > RCS file: /space2/ncvs/src/lib/libc/uuid/uuid.h,v > retrieving revision 1.2 > diff -u -p -r1.2 uuid.h > --- lib/libc/uuid/uuid.h 5 Nov 2002 10:55:16 -0000 1.2 > +++ lib/libc/uuid/uuid.h 5 Nov 2002 23:40:14 -0000 [snip] > @@ -45,7 +46,11 @@ > #define uuid_s_invalid_string_uuid 2 > #define uuid_s_no_memory 3 > > +/* XXX namespace pollution? */ > +typedef struct uuid uuid_t; > + The comment can be removed, because uuid_t is defined in DCE 1.1 and thus can never be namespace pollution. The comment did apply in , because that haeader was not DCE 1.1 compliant (only the struct definition). Moving the typedef to is probably a good idea anyway now that we have . > Index: sys/sys/uuid.h > =================================================================== > RCS file: /space2/ncvs/src/sys/sys/uuid.h,v > retrieving revision 1.2 > diff -u -p -r1.2 uuid.h > --- sys/sys/uuid.h 5 Nov 2002 10:57:53 -0000 1.2 > +++ sys/sys/uuid.h 5 Nov 2002 23:38:44 -0000 [snip] > @@ -50,8 +48,6 @@ struct uuid { > uint8_t node[_UUID_NODE_LEN]; > }; > > -#ifdef _KERNEL > - > #define UUID_NODE_LEN _UUID_NODE_LEN > > struct sbuf; Don't removed the #ifdef _KERNEL completely. There are prototypes that only apply in kernel land. You definitely don't want to leak UUID_NODE_LEN. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message