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: Alexandre Oliva <aoliva at redhat dot com>
- To: MaShimiao <mashimiao dot fnst at cn dot fujitsu dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Thu, 18 Dec 2014 03:44:10 -0200
- 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>
[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(-)
diff --git a/manual/memory.texi b/manual/memory.texi
index 0729e70..03242c3 100644
--- a/manual/memory.texi
+++ b/manual/memory.texi
@@ -376,9 +376,9 @@ this function is in @file{stdlib.h}.
@c fastbin_index ok
@c fastbin ok
@c catomic_compare_and_exhange_val_acq ok
-@c malloc_printerr dup @mtsenv
-@c if we get to it, we're toast already, undefined behavior must have
-@c been invoked before
+@c malloc_printerr dup ok [no @mtsenv, see below]
+@c if we get to malloc_printerr, undefined behavior must have been
+@c invoked, so don't bother propagating @mtsenv up the call chain
@c libc_message @mtsenv [no leaks with cancellation disabled]
@c FATAL_PREPARE ok
@c pthread_setcancelstate disable ok
--
Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/ FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer