Greg Hudson wrote:
>On Sun, 2004-09-05 at 19:52, Branko ÄŒibej wrote:
>
>
>>>I didn't think Windows really had the concept of file descriptors
>>>outside of the POSIX terarium, much less file descriptors which (by
>>>virtue of their numbers) map onto stdin/stdout/stderr.
>>>
>>>
>
>
>
>>Windows has all of that, even though it's simulated by the C runtime
>>library. That's why I'd like to see proof (either through testing, or
>>BDB code review) that this problem really doesn't occur on Windows
>>
>>
>
>BDB code review? I'm not sure how that could be relevant.
>
>
The problem shows up when a write to stdout finds its way into a file
opened by BDB, doesn't it? If BDB opens files differently on Windows
than it does on Unix, we're safe.
>On Unix, the bindings of fds 0/1/2 at process startup are purely in the
>hands of the calling process; the fork() and exec() calls don't care
>about them. In the Windows world,
>http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/createprocess.asp
>and
>http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/startupinfo_str.asp
>suggest that there is much more structure involved. I don't know what
>happens if you pass INVALID_HANDLE_VALID in the startup info structure,
>but it seems likely that Windows will do something intelligent (either
>mapping that file handle to the console, or mapping it to a null
>device).
>
Handles aren't really the issue here, because there are no "well-known"
handle values for the standard streams. But the CRT does provide a
file-descriptor-like interface where FD's 0, 1, and 2 _are_ special, and
the standard C FILE* streams stdin, stdout and stderr are bound to
those. Those streams can be closed just like on Unix, and from all I've
seen, stream slots are assigned sequentially. So we could potentially be
exposed to the same problem on Windows.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Sep 6 08:47:51 2004