apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Rumph <mike.ru...@oracle.com>
Subject Re: testdup test fails when compiled in debug mode on Windows
Date Thu, 07 Nov 2013 15:09:18 GMT
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.


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.rumph@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.

View raw message