Hello Bill,
That is a very good point, since the assert box will only appear under
debug mode.
But when not in debug mode _commit(2) will send back a "-1" return code
and set errno to EBADF,
if stderr is not redirected to a file.
The error existed in both cases, but the apr_file_dup2() function in
apr/file_io/win32/filedup.c was simply ignoring the return code from
_commit(). Perhaps it should be checked.
There is also the issue that Jeff uncovered for stdin having a reversed
effect from stdout and stderr.
Do you remember if the reasons for using _commit() would distinguish
between input and output?
We should probably also consider whether or not the fflush(stdin) call
makes sense as well, dependent on whether or not stdin is redirected or
piped in from another process.
Thanks,
Mike Rumph
On 11/6/2013 9:33 PM, William A. Rowe Jr. wrote:
On Wed, 06 Nov 2013 16:07:37 -0800
Mike Rumph <mike.ru...@oracle.com> wrote:
On 11/6/2013 1:06 PM, Jeff Trawick wrote:
I just played with _commit() on stdin a bit. It turns out that
_commit(0) fails if stdin is redirected (main.exe < somefile) but
works if stdin is a tty. That's the opposite of _commit(1 or 2).
But I don't see how _commit(0) makes sense anyway, so I simply
removed the call instead of reversing the corresponding _isatty()
check in your patch.
trunk: r1539455
1.5.x branch: r1539461
Okay Jeff,
I just tried both stdout and stdin, and got the same results that you
did. Strange but true.
IIRC the choice to _commit ahead of any handling of stdin/out/err
reflected the possibility that bytes were queued/stuck in the FILE or
the msvcrt 'fd' (not really an fd at all) before assuming ownership of
the file handle. It might have been an overreaction to a problem that
wouldn't exist in practice. But I'd prefer if this were left context
sensitive to _DEBUG mode builds.
