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 generally a problem with newer versions of Windows and services.

So apr_file_open_std* should just reference the existing
system descriptors. However it behaves like 'attach' rather then open,
meaning once you open it you will destroy the system stdin/stdout/stderr.
Thus by design it's a singleton operation, so if desired,
the second invocation during the process lifetime should always
return EBADF for apr_file_open_std* thought.


Very confusing.

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.

Regards,
Yura

Reply via email to