This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: question about env and function malloc
- From: Rich Felker <dalias at libc dot org>
- To: libc-alpha at sourceware dot org
- Date: Thu, 18 Dec 2014 23:47:13 -0500
- Subject: Re: question about env and function malloc
- Authentication-results: sourceware.org; auth=none
- References: <54744550 dot 80909 at cn dot fujitsu dot com> <ora92xzv4i dot fsf at free dot home> <5487B38B dot 8000804 at cn dot fujitsu dot com> <ortx12tddz dot fsf at free dot home> <548E888F dot 9090007 at cn dot fujitsu dot com> <ork31sblc0 dot fsf at free dot home> <5490E3CA dot 9000301 at cn dot fujitsu dot com> <ortx0t7brp dot fsf at free dot home>
On Thu, Dec 18, 2014 at 03:44:10AM -0200, Alexandre Oliva wrote:
> [Cc:ing the list]
>
> On Dec 17, 2014, MaShimiao <mashimiao.fnst@cn.fujitsu.com> wrote:
>
> > But, the description of env in glibc manual says if a function accesses
> > environment with getenv() of similar, without any guard, then it should be
> > marked with env. it doesn't mention any special functions.
> > Do you think we should add some words to remind users that there are some special
> > conditions in which even a function calls getenv(), it will not be marked with env.
> > Just like malloc() or free().
> > Or we just add explanations in the description of each special functions?
>
> I think a note at the exception point should be enough, as in the patch
> below.
This is a conformance issue; for the purpose of safety with respect to
modifying the environment in a multi-threaded program, the set of
standard functions allowed to access the environment is fixed by POSIX
and does not include malloc. The only conforming way functions outside
this fixed set can use the environment is to probe it during program
initialization (before any application-level code runs) and save the
result.
Rich