This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 1/9] Add vectorized getenv for glibc use
- From: Andi Kleen <andi at firstfloor dot org>
- To: Siddhesh Poyarekar <siddhesh at redhat dot com>
- Cc: Andi Kleen <andi at firstfloor dot org>, libc-alpha at sourceware dot org, Andi Kleen <ak at linux dot intel dot com>
- Date: Sat, 11 May 2013 00:32:40 +0200
- Subject: Re: [PATCH 1/9] Add vectorized getenv for glibc use
- References: <1367537252-30831-1-git-send-email-andi at firstfloor dot org> <1367537252-30831-2-git-send-email-andi at firstfloor dot org> <20130509093313 dot GE19683 at spoyarek dot pnq dot redhat dot com>
On Thu, May 09, 2013 at 03:03:13PM +0530, Siddhesh Poyarekar wrote:
> > + _dl_glibc_var;
> > + __glibc_var_init;
>
> These should be sorted.
FWIW the existing entries are not sorted. I moved my new ones.
>
> i < GLIBC_VAR_MAX may be a better termination check since it should
> help unroll this loop.
I changed it, although I would consider any compiler that unrolls
this loop broken.
> > +enum
> > +{
> > + GLIBC_VAR_MUTEX,
> > + GLIBC_VAR_RWLOCK,
> > + GLIBC_VAR_MAX
> > +};
> > +
>
> We might want to enforce namespaces from the beginning here. How
> about GLIBC_PTHREAD_MUTEX_TYPE or similar? I don't want to bikeshed
> on the actual name; I'm fine as long as a good namespace convention is
> established.
The environment variables are called GLIBC_MUTEX and GLIBC_RWLOCK
I don't think it makes sense to call the internal names anything
else.
> It might also be a good idea to typedef the enum as glibc_env_t (or
> similar) and enforce that on users of the function instead of
> accepting any int.
Did not do this as discussed earlier.
I did all the other changes you asked for.
-Andi
--
ak@linux.intel.com -- Speaking for myself only.