apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Reid" <dr...@jetnet.co.uk>
Subject Re: cvs commit: apr/file_io/unix filedup.c
Date Tue, 08 Jan 2002 16:01:00 GMT
Sorry, but I really don't like this patch.

The problem that we had wouldn't have been addressed by this patch anyways,
and we are a library - so why are we trying to tell users what they can and
can't do?

I'd like to revert this patch.

I think we should also have a _dup2 version of this function, but I think we
shoudl basically do just what dup/dup2 do and not try to get overly fancy.
We're a library, not a babysitter!

david

> wrowe       02/01/07 19:45:09
>
>   Modified:    file_io/unix filedup.c
>   Log:
>     We cannot close-on-fork any fd 0 through 2 (stdin, stdout, stderr)!!!
>     This patch is possibly still borked, we probably should remove any
>     existing cleanup registered again (*new_file) if it was given.
>
>     This api really is dirty, should really have an apr_file_dup2() with
>     different conventions (passing apr_file_t* for both left and right
args.)
>     I can see users 'forgetting' to null the target apr_file_t**
destination.
>



Mime
View raw message