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: Alexandre Oliva <aoliva at redhat dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Mon, 22 Dec 2014 13:30:18 -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> <20141219044713 dot GX4574 at brightrain dot aerifal dot cx> <orr3vr5yiq dot fsf at free dot home>
On Mon, Dec 22, 2014 at 04:29:17PM -0200, Alexandre Oliva wrote:
> On Dec 19, 2014, Rich Felker <dalias@libc.org> wrote:
>
> > 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 âenvâ safety note quite often indicate deviations from the standard
> anyway, so I don't see what light your statement sheds on the issue at
> hand. Can you please elaborate? TIA,
OK, if this is a known issue that's being left for later, then my
comment doesn't really add anything.
Rich