Juergen Boemmels <[EMAIL PROTECTED]> wrote:
> No, I think we need to rethink the wrapping technology (which I
> introduced). Something like:
> struct parrot_io_t {
> PObj pobj;
> UINTVAL flags;
> PIOHANDLE fd;
> ...
> };
> But this needs to allocate garbage-collected memory of
> sizeof(str
e speed but makes
debugging easier. Toughts?
They should do exactly that. Speed differences of 3-4 cycles are
lost in the noise of IO calls anyway.
> PIO_eof() returns true if the PMC has a null IO object or if
> the PIO_F_EOF flag is set.
>
> >Is the "io == NULL" tes
Melvin Smith <[EMAIL PROTECTED]> writes:
> At 11:45 AM 11/24/2003 +0300, Vladimir Lipsky wrote:
> >Hi everyone!
> >
> >In t/src/io.c, specifically test 9 and 10, I wonder if the PIO_eof check up
> >works anywhere; because I didn't manage to find any place
> Currently it isn't prohibitied. That is the only way to detect an error
> from PIO_open* at this time.
io = PIO_open(interpreter, NULL, file[i], flags[j]);
if ( (PIO_eof(interpreter, io) ? 0:1) != expected[i][j] )
{
0x4c56
At 11:45 AM 11/24/2003 +0300, Vladimir Lipsky wrote:
Hi everyone!
In t/src/io.c, specifically test 9 and 10, I wonder if the PIO_eof check up
works anywhere; because I didn't manage to find any place where the
PIO_F_EOF flag is set up when the PIO_*_open function fails neither
in io_st
Hi everyone!
In t/src/io.c, specifically test 9 and 10, I wonder if the PIO_eof check up
works anywhere; because I didn't manage to find any place where the
PIO_F_EOF flag is set up when the PIO_*_open function fails neither
in io_stdio.c, io_unix.c nor io_win32.c
Is the "io == NUL
