apr-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@covalent.net>
Subject Re: cvs commit: apr/file_io/unix filedup.c
Date Fri, 11 Jan 2002 10:00:13 GMT
> dreid       02/01/11 01:04:51
> 
>   Modified:    include  apr_file_io.h
>                file_io/unix filedup.c
>   Log:
>   Add apr_file_dup2.
>   
>   This has implications in that we now only do dup2 when we call
>   apr_file_dup2 and this will potentially cause problems for code
>   using apr_file_dup. The changes attempt to follow posix more closely.

Well, more to the point, doesn't vary the behavior based on a (apr_t **result)
arg that folks might not initialize :)  In fact, I wondered why you didn't
change the type to apr_file_t *dup2_file?

>   Will Rowe is going to tackle Win32 and OS/2 today.
>   Changes to apache on the way.

I'm afraid I'm out-of-time [hoped your patch would be in wed eve.]
Win32 is done, if you adopt the *dup2_file instead of **dup2_file, please
fix win32's (*new_file)-> entries to new_file->.  

>   Issues: what should we do for dup2 when we have differing pools being
>   used?

Well, if the file exists, we should use the existing apr_file_t's pool, since
it dies when it goes out of scope.  Don't register a cleanup, it should have
done so already

The old apr_file_dup should always use the *p for things like filename dup,
etc.  Win32's code was very broken these ways, before I just fixed it.

Bill


Mime
View raw message