X-Authentication-Warning: delorie.com: mail set sender to djgpp-workers-bounces using -f
From: "Juan Manuel Guerrero" <st001906 AT hrz1 DOT hrz DOT tu-darmstadt DOT de>
Organization: Darmstadt University of Technology
To: djgpp-workers AT delorie DOT com
Date: Tue, 07 Dec 2004 17:15:07 +0200
MIME-Version: 1.0
Subject: Re: A fix for popen()
Message-ID: <41B5E51B.9304.37DF4A0@localhost>
In-reply-to: <200412071548.iB7FmBY0001370@envy.delorie.com>
References: <Pine DOT OSF DOT 4 DOT 58 DOT 0412071254320 DOT 19658 AT sirppi DOT helsinki DOT fi> (message	from Esa A E Peuha on Tue, 7 Dec 2004 13:02:04 +0200 (EET))
X-mailer: Pegasus Mail for Windows (v4.02a, DE v4.02 R1)
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Content-description: Mail message body
X-TUD-HRZ-MailScanner: Found to be clean
X-MailScanner-From: st001906 AT hrz1 DOT hrz DOT tu-darmstadt DOT de
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

On Tue, 7 Dec 2004, DJ Delorie wrote:
> While your patch will fix that problem, setting l1->command to NULL
> fixes that problem *and* the other problems, so it is a better patch.
> 
> No reason why we can't have both patches (unless we later change
> something in popen/pclose that sets l1->command for other reasons),
> but l1->command still needs to be initialized.
> 
> Personally, I prefer a more paranoid approach - if command is set,
> even if we don't expect it to be, it needs to be freed.

I prefer this approach too but I do not want to interfer in this discussion.
The important issue here is the to notice that the patch proposed by Esa
this morning still does not resolve the complete issue. The patch inhibits
the call to free() in pclose but left the same malign code:
 error:

  if (l1->command)
    free(l1->command);

  if (temp_name)
    free(temp_name);

in popen(). This will make either sed ot texinfo breake (I do not remeber
which one of both). It must be avoided to deallocate *command pointer
inconditionaly.

Regards,
Juan M. Guerrero