Date: Sun, 10 Nov 2002 11:40:48 -0800 From: Marcel Moolenaar <marcel@xcllnt.net> To: Maxime Henrion <mux@freebsd.org> Cc: current@freebsd.org Subject: Re: uuid.h is not C++ safe Message-ID: <20021110194048.GA542@athlon.pn.xcllnt.net> In-Reply-To: <20021110120411.GV26605@elvis.mu.org> 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> <20021106013345.GA1633@athlon.pn.xcllnt.net> <20021110120411.GV26605@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Nov 10, 2002 at 04:04:11AM -0800, Maxime Henrion wrote: > Marcel Moolenaar wrote: > > 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 > > > > <uuid.h>, 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 <sys/uuid.h>. Suggestions? > > > > > > Well I don't really understand what you mean here. > > > > I'm not sure I like uuidgen(2) in <uuid.h>. <uuid.h> is the DCE 1.1 > > compliant interface to UUIDs. <sys/uuid.h> describes the underlying > > generic interface on which <uuid.h> 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 <uuid.h> was included already. There is > > a difference when only <sys/uuid.h> was included before. One cannot > > use uuidgen(2) without also including the DCE 1.1 compliant stuff. > > What about having uuidgen(2) in sys/uuid.h, but hidden by a > _UIDGEN_VISIBLE macro ? That's not very elegant but it will help not > polluting the DCE 1.1 namespace with the syscall and let applications > which need it (gpt and uuidgen IIRC) have it declared. > > Of course, we could also have a third header just for uuidgen(2). Hmmm. A third header is just too much. I'd much rather we keep it where it is, visible and all, until we have a problem. This will not happen before we have a full libdce implementation I would say. But then things probably get shuffled around anyway. Note: only uuidgen(1) uses uuidgen(2). All other UUID consumers, with obviously the exception of uuid_create(3), use the DCE 1.1 interface. Making uuidgen(2) invisible is not infeasible. However, uuidgen(1) is a well-known command and I think there's benefit to keep uuidgen(2) visible. I don't think it's that unrealistic to speculate on the possible future that uuidgen(2) will be a backend (low-level) interface on more OSes. The best way to speculate is if you help force it :-) -- 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021110194048.GA542>