Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Date: Tue, 17 Feb 2004 12:33:34 -0500 From: Christopher Faylor To: cygwin AT cygwin DOT com Subject: Re: failure of unzip and recent cygwin1.dll Message-ID: <20040217173334.GA25216@redhat.com> Mail-Followup-To: cygwin AT cygwin DOT com References: <3 DOT 0 DOT 5 DOT 32 DOT 20040216213234 DOT 007fa580 AT incoming DOT verizon DOT net> <20040217160939 DOT GC22509 AT redhat DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040217160939.GC22509@redhat.com> User-Agent: Mutt/1.4.1i X-IsSubscribed: yes Reply-To: cygwin AT cygwin DOT com On Tue, Feb 17, 2004 at 11:09:39AM -0500, Christopher Faylor wrote: >>I believe a destructor would be cleaner, and the current code obviously >>misses at least one more place where this is needed. Unfortunately, with >>my copyright assignment in flux, I can't send in a patch. If noone fixes >>this by the time I can send patches, I'll try to send in a fix for this. > >It's not that simple. path_conv objects can persist, even over fork/exec. >So a simple destructor would be guaranteed to do the wrong thing. Actually maybe it is that simple. In my exhaustive testing (i.e., one program) it seems like a destructor works just fine. This is, I suppose, a tribute to the person who wrote most of the path handling code. I should have had more faith in his abilities. On reflection, another reason for not doing things this way was to avoid the cost of a destructor for all of the cases that path_conv was used when it wasn't really needed for the vast majority of cases. I've been trying to move more and more to using fhandler_* instead of path_conv and fhandler does free normalized_path. However, I obviously haven't done a 100% conversion so it's better to be safe. I'm running the test suite now. If cygwin survives with the destructor, I'll check it in and generate a snapshot. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/