Mladen Turk wrote: > On 16/10/09 16:56, William A. Rowe, Jr. wrote: >> Mladen Turk wrote: >>> >>> What 99% users would need is apr_file_attach_std* set of functions >>> giving the apr_file_t capable API without destroying the system >>> std streams. >>> >>> And we should probably protect the sigleton apr_file_open_std* >>> against multiple invocations, cause the always acts upon a >>> singleton std stream object. >> >> We already have it. >> >> Simply don't call close() :) >> > > Sure. However we should at least return EBADF on a second > invocation cause we know the first one will destroy stdout when > closed (directly, via pool destroy or via terminate)
apr_file_open_std* should not auto-close the underlying file stream ever, only the apr_file_t pointer. If apr_file_t is then dup'ed to a std* stream, then again all bets will be off once apr_terminate is invoked. Perhaps all will be well, but no assurance. > For 2.0 apr_file_attach_std* might be a valuable addition > for repetitive apr_file_t objects allowing file API without > jeopardizing the stream integrity. In 2.0, we can simply change such semantics.
