failure of unzip and recent cygwin1.dll

Christopher Faylor cgf-no-personal-reply-please@cygwin.com
Tue Feb 17 17:51:00 GMT 2004


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/



More information about the Cygwin mailing list