From jeremyp@gsmx07.alcatel.com.au Mon Mar  1 14:56:18 1999
Return-Path: <jeremyp@gsmx07.alcatel.com.au>
Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10])
	by hub.freebsd.org (Postfix) with ESMTP id B733E155CA
	for <FreeBSD-gnats-submit@FreeBSD.ORG>; Mon,  1 Mar 1999 14:56:15 -0800 (PST)
	(envelope-from jeremyp@gsmx07.alcatel.com.au)
Received: by border.alcanet.com.au id <40323>; Tue, 2 Mar 1999 09:44:35 +1100
Message-Id: <99Mar2.094435est.40323@border.alcanet.com.au>
Date: Tue, 2 Mar 1999 09:55:47 +1100
From: Peter Jeremy <jeremyp@gsmx07.alcatel.com.au>
Reply-To: peter.jeremy@alcatel.com.au
To: FreeBSD-gnats-submit@FreeBSD.ORG
Cc: jeremyp@gsmx07.alcatel.com.au
Subject: putenv(3) unnecessarily calls strdup/free
X-Send-Pr-Version: 3.2

>Number:         10342
>Category:       bin
>Synopsis:       putenv(3) unnecessarily calls strdup/free
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Mar  1 15:00:00 PST 1999
>Closed-Date:    Thu Jul 13 07:23:42 PDT 2000
>Last-Modified:  Thu Jul 13 07:25:28 PDT 2000
>Originator:     Peter Jeremy
>Release:        FreeBSD 3.0-CURRENT i386
>Organization:
Alcatel Australia Limited
>Environment:

	putenv.c 1.1

>Description:

	putenv(3) uses strdup to create a local copy of the passed
	environment string so it can replace the `=' with NUL to
	pass a NUL-terminated name to setenv(3).  Since setenv(3)
	will accept a `='-terminated name (this is documented, as
	well as actual behaviour), this is unnecessary.	

>How-To-Repeat:

	Study manual page and code for setenv(3).

>Fix:
	
	Change putenv.c to:

int
putenv(str)
        const char *str;
{
        char *equal;

        if ((equal = index(str, '=')) == NULL) {
                return (-1);
        }
        return (setenv(str, equal + 1, 1));
}

>Release-Note:
>Audit-Trail:

From: Peter Jeremy <peter.jeremy@alcatel.com.au>
To: freebsd-gnats-submit@FreeBSD.ORG
Cc:  
Subject: Re: bin/10342: putenv(3) unnecessarily calls strdup/free
Date: Wed, 22 Dec 1999 13:47:21 +1100

 Since the correct fix is not clear, how about at least documenting
 the problem:
 
 Index: src/lib/libc/stdlib/getenv.3
 ===================================================================
 RCS file: /home/CVSROOT/src/lib/libc/stdlib/getenv.3,v
 retrieving revision 1.3
 diff -u -r1.3 getenv.3
 --- getenv.3	1999/08/28 00:01:31	1.3
 +++ getenv.3	1999/10/05 06:26:19
 @@ -150,3 +150,13 @@
  .Fn putenv
  function appeared in
  .Bx 4.3 Reno .
 +.Sh BUGS
 +Successive calls to
 +.Fn setenv
 +or
 +.Fn putenv
 +assigning a differently sized
 +.Ar value
 +to the same
 +.Ar name
 +will result in a memory leak.
 
 Peter
 

From: Peter Jeremy <peter.jeremy@alcatel.com.au>
To: rgrimes@gndrsh.dnsmgr.net
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: bin/10342: putenv(3) unnecessarily calls strdup/free
Date: Thu, 27 Jan 2000 07:21:26 +1100

 Hi Rod,
 
 I know it's been a while, but you were the last person to touch
 /usr/src/lib/libc/stdlib/putenv.c.  Could you please consider
 applying the following to close PR bin/10342:
 
 	Change putenv.c to:
 
 int
 putenv(str)
         const char *str;
 {
         char *equal;
 
         if ((equal = index(str, '=')) == NULL) {
                return (-1);
         }
         return (setenv(str, equal + 1, 1));
 }
 
 Peter
 

From: "Rodney W. Grimes" <rgrimes@gndrsh.dnsmgr.net>
To: peter.jeremy@alcatel.com.au (Peter Jeremy)
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: bin/10342: putenv(3) unnecessarily calls strdup/free
Date: Wed, 26 Jan 2000 14:18:23 -0800 (PST)

 > Hi Rod,
 > 
 > I know it's been a while, but you were the last person to touch
 > /usr/src/lib/libc/stdlib/putenv.c.  Could you please consider
 > applying the following to close PR bin/10342:
 
 No I won't make this change:
 a)  This is tried and true tested code that has not been modified
     since 4.4BSD Lite.
 b)  The man page says ``the given arguments name and value may be appended
     and prepended, respectively, with an equal sign ``=''.''  It does not
     say that you can have additional stuff after the =, your patch leaves
     stuff after the =.
 
 The PR eludes to a memory leak, can you be more specific on exactly how
 this memory leak occurs as I do not see a memory leak in putenv as the
 code is now.
 
 
 -- 
 Rod Grimes - KD7CAX @ CN85sl - (RWG25)               rgrimes@gndrsh.dnsmgr.net
 

From: Peter Jeremy <peter.jeremy@alcatel.com.au>
To: "Rodney W. Grimes" <rgrimes@gndrsh.dnsmgr.net>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: bin/10342: putenv(3) unnecessarily calls strdup/free
Date: Thu, 27 Jan 2000 09:56:47 +1100

 On 2000-Jan-27 09:19:24 +1100, "Rodney W. Grimes" <rgrimes@gndrsh.dnsmgr.net> wrote:
 >a)  This is tried and true tested code that has not been modified
 >    since 4.4BSD Lite.
 Accepted.  (Though I don't believe that this _automatically_ makes the
 code perfect).
 
 >b)  The man page says ``the given arguments name and value may be appended
 >    and prepended, respectively, with an equal sign ``=''.''  It does not
 >    say that you can have additional stuff after the =, your patch leaves
 >    stuff after the =.
 
 A slight difference in interpretation: I read the manual page as
 meaning that the name argument to setenv() could be _terminated_ with
 either NUL ('\0') or '=' - ie what came after the '=' is irrelevant.
 
 The current implementation of setenv() (and __findenv()) does treat a
 trailing '=' as a terminator.  (And I'm not sure how/why someone would
 write code that accepted and ignored '=', but did not treat it as a
 terminator).
 
 >The PR eludes to a memory leak, can you be more specific on exactly how
 >this memory leak occurs as I do not see a memory leak in putenv as the
 >code is now.
 
 An associated PR (bin/10341) discusses a memory leak in setenv()
 (which was previously mentioned in bin/5604).  I have no evidence for
 a memory leak within putenv() itself (though my demonstration code for
 bin/10341 uses putenv()).  My bin/10342 was solely an efficiency
 improvement (removing calls to strdup/free).
 
 If you are not comfortable with this change, I'll accept your right to
 refuse to apply it.  I was just going through my outstanding PR's and
 prodding people over the ones I saw as trivial.
 
 Peter
 

From: "Rodney W. Grimes" <rgrimes@gndrsh.dnsmgr.net>
To: peter.jeremy@alcatel.com.au (Peter Jeremy)
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: bin/10342: putenv(3) unnecessarily calls strdup/free
Date: Wed, 26 Jan 2000 17:34:05 -0800 (PST)

 > On 2000-Jan-27 09:19:24 +1100, "Rodney W. Grimes" <rgrimes@gndrsh.dnsmgr.net> wrote:
 > >a)  This is tried and true tested code that has not been modified
 > >    since 4.4BSD Lite.
 > Accepted.  (Though I don't believe that this _automatically_ makes the
 > code perfect).
 
 I'll counter with the fact that the code as written is extreamly safe
 and independent of specific, and possibly non-standard, implementations
 of setenv.
 
 > >b)  The man page says ``the given arguments name and value may be appended
 > >    and prepended, respectively, with an equal sign ``=''.''  It does not
 > >    say that you can have additional stuff after the =, your patch leaves
 > >    stuff after the =.
 > 
 > A slight difference in interpretation: I read the manual page as
 > meaning that the name argument to setenv() could be _terminated_ with
 > either NUL ('\0') or '=' - ie what came after the '=' is irrelevant.
 > 
 > The current implementation of setenv() (and __findenv()) does treat a
 > trailing '=' as a terminator.  (And I'm not sure how/why someone would
 > write code that accepted and ignored '=', but did not treat it as a
 > terminator).
 
 Looking at implementation is probably not a good idea, as that may
 change.  Also depending on behavior not in Posix may cause problems
 down the road.  What does Posix say about the semantics of any of this,
 I see the man page has no posix reference and only getenv is references
 to ISO C.
 
 I also have great concerns that this type of auto termination assumption
 is leading to things like:
 # env
 ...
 XXX=adsfasdf=
 ...
 
 Now you tell me.... how did I do that, and is the env name
 XXX or XXX=asdfasdf  and just how is getenv/setenv/putenv going
 to deal with this, let alone a program.
 
 [Okay, I'll give you a hint, it was set with csh(1) and here is what
 sh(1) does with a few echo's
 # echo ${XXX}
 adsfasdf=
 # echo ${XXX=adsfasdf}
 adsfasdf=
 # 
 
 Can you see why this whole idea of trying to do the = simplification
 has lead to a rotting crock of shit??
 
 > >The PR eludes to a memory leak, can you be more specific on exactly how
 > >this memory leak occurs as I do not see a memory leak in putenv as the
 > >code is now.
 > 
 > An associated PR (bin/10341) discusses a memory leak in setenv()
 > (which was previously mentioned in bin/5604).  I have no evidence for
 > a memory leak within putenv() itself (though my demonstration code for
 > bin/10341 uses putenv()).  My bin/10342 was solely an efficiency
 > improvement (removing calls to strdup/free).
 
 I think Archie just commited the man page changes to document the
 leak.  Efficiency that can lead to bugs due to reading the implementation
 of another part of the code is a bug waiting to happen.
 
 > 
 > If you are not comfortable with this change, I'll accept your right to
 > refuse to apply it.  I was just going through my outstanding PR's and
 > prodding people over the ones I saw as trivial.
 
 Infact now that you have made me really go look at this, I would like
 to ask that you close this PR as ``a bad idea''.  Micro optimization
 that can lead to one blowing your toe off is not a good thing.
 
 -- 
 Rod Grimes - KD7CAX @ CN85sl - (RWG25)               rgrimes@gndrsh.dnsmgr.net
 

From: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
To: "Rodney W. Grimes" <rgrimes@gndrsh.dnsmgr.net>
Cc: freebsd-bugs@FreeBSD.org
Subject: Re: bin/10342: putenv(3) unnecessarily calls strdup/free
Date: Wed, 26 Jan 2000 23:12:28 -0500 (EST)

 <<On Wed, 26 Jan 2000 17:40:02 -0800 (PST), "Rodney W. Grimes" <rgrimes@gndrsh.dnsmgr.net> said:
 
 >  Looking at implementation is probably not a good idea, as that may
 >  change.  Also depending on behavior not in Posix may cause problems
 >  down the road.
 
 Which is why portable programs must not use setenv(), which is not a
 POSIX interface (nor is it in SUSv2).
 
 -GAWollman
 
 
 
 To Unsubscribe: send mail to majordomo@FreeBSD.org
 with "unsubscribe freebsd-bugs" in the body of the message
 
State-Changed-From-To: open->closed 
State-Changed-By: nbm 
State-Changed-When: Thu Jul 13 07:23:42 PDT 2000 
State-Changed-Why:  
rgrimes suggested this PR be closed, and provides reasoning in the audit 
trail. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=10342 
>Unformatted:
