This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Making getenv more multi-threading--robust?
- From: KOSAKI Motohiro <kosaki dot motohiro at gmail dot com>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: Stephan Bergmann <sbergman at redhat dot com>, libc-alpha at sourceware dot org
- Date: Thu, 13 Sep 2012 17:06:15 -0400
- Subject: Re: Making getenv more multi-threading--robust?
- References: <5051BBEF.4080401@redhat.com> <20120913170350.E17A42C0CE@topped-with-meat.com>
> POSIX does not require getenv vs setenv to be thread-safe, but Solaris
> documents it as being thread-safe.
We have one another glibc specific issue. glibc malloc uses getenv()
internally but
it is pure implementation internal. Many developers don't think malloc
vs setenv is
unsafe. Moreover it's undocumented unfortunately.
> So I think it's a reasonable change.
> File a bug in bugzilla about it first.
Or reopen 5069 or 4887?
They seems to discuss very similar or the same issue.
> Put the definition of the lock in getenv.c, so that when linking
> statically, using getenv does not force setenv to be linked in.
>
> getenv.c is already not intended to be built outside libc, so there is no
> need for #ifdef _LIBC in there. setenv.c is shared with gnulib (though
> they are out of synch), so maintaining its existing conditionalization is
> appropriate.