apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: Crash in apr_file_close() (Linux)
Date Fri, 16 Oct 2009 15:51:50 GMT
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.

Mime
View raw message