> This is a missing implementation of fdopen on windows.
> Its not clear to me how this call should behave. PIO_win32_fdopen
> takes a Parrot_WIN32_Handle which is actually a void*.
To my mind the imlementation is fine.
> Using the numbers 0,1,2 in this call does not seem right
> here. Especially since we decided to drop the integer file handles
> (perl #22899).
The main problem here is that 0, 1, 2 make no sense in
windows. Win32 API uses handles of the type HANDLE,
which, as you already told, is actually void*, and not
file descriptors. I bet that PIO_stdio_fdopen doesn't
work either, since stdio makes use of FILE*, you know.
I like your PIOHANDLE abstraction, why not to intdroduce
yet another one but over the 3rd parameter of PIO_*_fdopen.
I presume it won't hurt us much. The abstraction could be
incarnated as a new pmc named parrotfd. Then we would be
allowed to have
inline op getfd(out PMC, in PMC) {
and
inline op fdopen(out PMC, in PMC, in STR) {
Beyond doubt this will solve the problem of fdopen
and we will be able to get rid of numbers forever.
The io_3.pasm test could look the following way
output_is(<<'CODE', <<'OUTPUT', "fdopen");
getstdout P0
getfd P1, P0
fdopen P2, P1, ">"
defined I0, P2
unless I0, nok
print P2, "ok\n"
close P2
end
nok:
print "fdopen failed\n"
end
CODE
ok
OUTPUT
What do you think?
