At 04:24 PM 3/5/2003, Bjoern A. Zeeb wrote: >On Wed, 5 Mar 2003, William A. Rowe, Jr. wrote: > >> At 01:54 PM 3/5/2003, Joe Orton wrote: >> >I also wonder why the code goes to these lengths when on Unix setting >> >the CLOEXEC flag would probably suffice. >> >> We should do *either*; if CLOEXEC is supported and can be toggled >> per our API (_set/_unset) then that can be the preferred method, to protect >> ourselves from non-apr callers of exec(). (This goes for files, too.) > >THANKS !!!
You are welcome. >Perhaps then also have s.th. like an "alias" apr_pipe_(un)set_inherit to >apr_file_(un)set_inherit ? It perhaps would make some lines of code >more clear... No - because the API functions are not apr_pipe_foo. Pipes use the apr_file_ api, period. Since on all platforms they take an apr_file_t, it doesn't matter anyways. If there is any distinction, that will happen in the _create and _cleanup code as appropriate. (And that's inherit_[un]set, not visa versa :-) >< may be ignored > >Just 'cause I currently saw this: why is it named apr_file_cleanup on >1/2OS aaeh OS/2 and apr_unix_file_cleanup ? And it seems to be only >named file_cleanup for win32. Because you *shouldn't* know the internals of those cleanups. It's entirely irrelevant internals of APR. >Functions are also named apr_file_open or apr_file_pipe_create for >unix. So ich someone touches this perhaps we can also do some cleanup >for thos cleanup_fns ? Ok, I can hear you till here go *waaah* ;-)))) >If I am right with my limited apache/apr experience this functions >should be/"are" hidden from users so it should not be real problem ? Exactly - it should all be transparent to them. No user should be adding/removing the cleanups - it is up to the accessors such as apr_file_inherit_[un]set to do such things. Bill
