Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 5 Nov 2002 17:33:45 -0800
From:      Marcel Moolenaar <marcel@xcllnt.net>
To:        Maxime Henrion <mux@freebsd.org>
Cc:        Juli Mallett <jmallett@freebsd.org>, Patrick Hartling <patrick@137.org>, current@freebsd.org
Subject:   Re: uuid.h is not C++ safe
Message-ID:  <20021106013345.GA1633@athlon.pn.xcllnt.net>
In-Reply-To: <20021105234624.GI26605@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>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

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 <sys/uuid.h>, because that haeader was not DCE 1.1 compliant
(only the struct definition). Moving the typedef to <uuid.h> is
probably a good idea anyway now that we have <uuid.h>.

> 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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021106013345.GA1633>