libassuan fails pipeconnect test on W32

[Werner Koch]

On Thu,  6 Jun 2013 10:18, lrn1986 at gmail.com said:

> but fails, because it's trying to write into CRT file descriptor using
> WriteFile(). Apparently, there needs to be some code to convert
> fileno(stdout) into handle that WriteFile() understands. Or

That is actually a big problem: We have many different classes of
handles and file descriptors and try to convey the using one scalar
type.  We spend many many debugging hours for the simple reason that we
were not always sure what object we are looking at.  It is a real mess.

> I suspect that the code that needs modification is
> parse_std_file_handles(). It has some W32CE-only code that appears to be
> doing the right thing (that is, if the spawn function (or whatever calls
> the spawn function) does pass the fd via command line), i wonder why
> it's CE-only...That said, converting fileno(stdout) to HANDLE is

CE is quite special because it has no pipes - we use our own pipe
emulation driver.  Another reason is that I did not want to get a
regression in plain W32 while doing the W32CE code.

> trivial, so there's no need to use that CE code. Just a few
> _get_osfhandle() calls with an #ifdef _WIN32.

Back and forth converting them is not easy to maintain.  Remember that
we also use sockets which are yet another kind of object.  For example
you may use select with a socket but not with a file handle and vice
versa.

The only clean solution I see is to give up on scalar type for these
objects and instead allocate transfer an object which can keep track of
the actual type.  That requires quite some changes and wrappers for
almost all I/O functions.  For a full 64 bit version of GnuPG on
Windows this should be done.

I am working on a 64 bit version of libassuan, thus I probably need to
look into the pipeconnect test, anyway.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.