> 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*.

Yup. I've alredy peeped in io.h, io_win32.c. And as soon as
I get more familiar with PIO, I'll try to say what the fdopen
implementation on windows is a lack of.

> 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).

Okay. I'll take a look.

> > t/pmc/io...............NOK 5#     Failed test (t/pmc/io.t at line 66)
> > #          got: 'ok 1
> > # ok 2
> > # not ok 3
> > # ok 4
> > # ok 5
> > # ok 6
> > # '
> > #     expected: 'ok 1
> > # ok 2
> > # ok 3
> > # ok 4
> > # ok 5
> > # ok 6
> > # '
>
> get_bool calls PIO_eof, which only checks io->flags & PIO_F_EOF. The
> win32 read function does not seem to set this flag correct. It looks
> correct but without win32 I cant debugg this.
>
> Can you run parrot t/pmc/io_5.pasm in the debugger, break on
> PIO_win32_read and look if the line
>   io->flags |= PIO_F_EOF;
> is reached?

I can't build pdb on win32 with nmake and MSVC, if you meant
that debbuger:

Microsoft (R) Program Maintenance Utility   Version 6.00.8168.0
Copyright (C) Microsoft Corp 1988-1998. All rights reserved.

pdb.c
pdb.c
        link -out:pdb
.obj -nologo -nodefaultlib -debug -pdb:none    -machine
:x86 blib/lib/libparrot_s.lib oldnames.lib kernel32.lib user32.lib gdi32.lib
win
spool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib
netapi32.
lib uuid.lib wsock32.lib mpr.lib winmm.lib version.lib odbc32.lib
odbccp32.lib m
svcrt.lib
CVPACK : fatal error CK1003: cannot open file: pdb.exe
LINK : warning LNK4027: CVPACK error
NMAKE : fatal error U1077: 'link' : return code '0x1'
Stop.

Anyway, TIMTOWTDI. I've checked around it's never reached,
'cause ReadFile returns 1 no matter whether you read more than
1 byte or less. I've attached a ????around[1] and now it successfully
passes io_5.pasm on Win32.

> > t/pmc/io...............NOK 19#     Failed test (t/pmc/io.t at line 274)
> > #          got: 'Can't spawn ".\parrot.exe --gc-debug t/pmc/io_15.pasm":
Bad
> > fil
> > e descriptor at lib/Parrot/Test.pm line 61.
> > # '
> > #     expected: 'ok 1
> > # Hello Parrot!
> > # '
> > # '.\parrot.exe --gc-debug t/pmc/io_15.pasm' failed with exit code 255
>
> why can't it spawn .\parrot.exe only in this test all other tests seem
> to have no problem with spawning. Try to run this test by hand
> \parrot.exe t/pmc/io_15.pasm

Bi-bi (~8 .. In itself io_15.pasm is okay. The problem(?) was
that there wasn't close FOO before openning the same file
for writing which the FOO file handle pointed to. The
attachment fixes it.

Though the whole thingy leaves me wondering how the perl
filehandles could be linked with the parrot io objects.
A mending in the attachment fixes the problem(?).

        ..
[1] wurgaround.


Attachment: diff
Description: Binary data

Reply via email to