question about env and function malloc

  [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.

Ok to install?


for ChangeLog

	* manual/memory.texi (malloc): Elaborate rationale to drop
	@mtsenv from malloc_printerr.
---
 manual/memory.texi |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
  

On 12/18/2014 01:44 PM, Alexandre Oliva wrote:
> I think a note at the exception point should be enough, as in the patch
> below.
> 
> Ok to install?
> 
> 
> for ChangeLog
> 
> 	* manual/memory.texi (malloc): Elaborate rationale to drop
> 	@mtsenv from malloc_printerr.
LGTM.


Best regards
  

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
  

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,
  

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