Paolo Bonzini wrote: > Also, actually the flags can be accessed; it's undocumented but it can > be found. See for example these files, taken from Perl and Ruby > respectively: > > http://downloads.activestate.com/contrib.old/ntsock.cpp > http://www.google.com/codesearch/p#-ImLthoNrik/ruby-1.8.6/win32/win32.c > > (search for _osfile).
In this code, _osfile() is defined as a macro that makes a lot of assumptions about the internal structure of an MSVCRT internal array. Additionally you see code that indicates that in certain newer versions of Windows, they have to *search* for a handle in memory in order to correct these assumptions. To me, this means: Poisoned! Don't touch! > > But the flags stored inside MSVCRT for fd cannot be directly accessed. > > I think we're safe if we only support _setting_ the flag, and not clearing it. > Most of the use cases are like this. Interesting idea. Yes, when the MSVCRT internal flags don't contain FNOINHERIT but the handle is set to not inheriting, the child will see an "open" file descriptor pointing to INVALID_HANDLE_VALUE. Remains to see which kinds of child processes can cope with this situation. Bruno
