Dear developers,
For some reason in my program I need two file handlers of stdout stream.
When I close these handlers I obtain an error on the second close: Bad
file descriptor
Here is the simple testcase code:
#include stdlib.h
#include stdio.h
#include apr.h
#include apr_pools.h
#include
On Fri, 2009-10-16 at 15:26 +0700, Yuri V. Vishnevskiy wrote:
For some reason in my program I need two file handlers of stdout
stream.
If you duplicate the descriptor with apr_file_dup() instead of calling
apr_file_open_stdout() twice, does it still do the same?
--
Bojan
On Fri, Oct 16, 2009 at 03:26:31PM +0700, Yuri V. Vishnevskiy wrote:
Dear developers,
For some reason in my program I need two file handlers of stdout stream.
When I close these handlers I obtain an error on the second close: Bad
file descriptor
It seems like reasonable behaviour that the
On 16/10/09 10:26, Yuri V. Vishnevskiy wrote:
Dear developers,
For some reason in my program I need two file handlers of stdout stream.
Could anybody try to reproduce this problem?
Crash happens on windows as well, so it might be a real
thing.
If you need two file objects perhaps a dup could
On Fri, 2009-10-16 at 15:26 +0700, Yuri V. Vishnevskiy wrote:
For some reason in my program I need two file handlers of stdout
stream.
If you duplicate the descriptor with apr_file_dup() instead of calling
apr_file_open_stdout() twice, does it still do the same?
With apr_file_dup()
On 16/10/09 10:39, Joe Orton wrote:
It seems like reasonable behaviour that the second apr_file_close() call
should fail, though it certainly isn't obvious from reading the docs.
How else do you expect it to behave? You cannot close an fd twice.
I suppose it shouldn't crash the apr.
IMO
On Fri, Oct 16, 2009 at 10:54:13AM +0200, Mladen Turk wrote:
On 16/10/09 10:39, Joe Orton wrote:
It seems like reasonable behaviour that the second apr_file_close() call
should fail, though it certainly isn't obvious from reading the docs.
How else do you expect it to behave? You cannot
On 16/10/09 11:01, Joe Orton wrote:
I think the reporter meant fail when they said crash.
Dunno what he meant but I confirmed last week's almost exact
report that crashes (really) windows.
I don't see any reason why it would crash on Unix: the first call to
apr_file_close() will set
On Fri, Oct 16, 2009 at 10:54:13AM +0200, Mladen Turk wrote:
On 16/10/09 10:39, Joe Orton wrote:
It seems like reasonable behaviour that the second apr_file_close()
call
should fail, though it certainly isn't obvious from reading the docs.
How else do you expect it to behave? You cannot
On Fri, Oct 16, 2009 at 11:17:17AM +0200, Mladen Turk wrote:
each invocation to apr_file_open_stdout creates a new apr_file_t so
each fd-filedes has a value of STDOUT_FILENO.
This is the same as calling:
close(1);
close(1);
Oh, good point. This is rather horrible :(. I'm not sure what can
On Fri, 16 Oct 2009 15:39:49 +0700, Joe Orton jor...@redhat.com wrote:
On Fri, Oct 16, 2009 at 03:26:31PM +0700, Yuri V. Vishnevskiy wrote:
Dear developers,
For some reason in my program I need two file handlers of stdout stream.
When I close these handlers I obtain an error on the second
On 16/10/09 11:21, Joe Orton wrote:
On Fri, Oct 16, 2009 at 11:17:17AM +0200, Mladen Turk wrote:
each invocation to apr_file_open_stdout creates a new apr_file_t so
each fd-filedes has a value of STDOUT_FILENO.
This is the same as calling:
close(1);
close(1);
Oh, good point. This is rather
I'm not sure why do we call close(0..2) for std files when
the apr_file_open_std* is closed or it's pool destroyed at the
first place.
Reading the:
* @remark The only reason that the apr_file_open_std* functions exist
* is that you may not always have a stderr/out/in on Windows. This
* is
On Fri, Oct 16, 2009 at 7:31 AM, Yuri V. Vishnevskiy
yuri.vishnevs...@gmail.com wrote:
This is related with another my problem. If I close stdout by
apr_file_close, then the standard printf and fprintf(stdout, ) functions are
no more working.
I've tested this on Windows and Linux.
If you
On 16/10/09 16:41, Jonathan Leffler wrote:
On Fri, Oct 16, 2009 at 7:31 AM, Yuri V. Vishnevskiy
yuri.vishnevs...@gmail.com mailto:yuri.vishnevs...@gmail.com wrote:
This is related with another my problem. If I close stdout by
apr_file_close, then the standard printf and fprintf(stdout,
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
If you close standard output, functions that write to standard output
should
not succeed - there is nowhere for the information to go. That is (or,
IMO,
should be) expected behaviour.
No doubt. Then how should I to use std* after apr_terminate()?
Yuri V. Vishnevskiy wrote:
If you close standard output, functions that write to standard output
should
not succeed - there is nowhere for the information to go. That is
(or, IMO,
should be) expected behaviour.
No doubt. Then how should I to use std* after apr_terminate()?
Once you call
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
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
No doubt. Then how should I to use std* after apr_terminate()?
Once you call apr_terminate(), all bets are off if you use such posix
entities
of apr objects. If apr_terminate() is closing the system-provided
stdin/out/err,
that is something we can fix either in 1.x (if it is
On Fri, Oct 16, 2009 at 09:56:50AM -0500, William Rowe 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
22 matches
Mail list logo
