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
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 where the
PIO_F_EOF flag is set up when the PIO_
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 testing prohibited in Parrot embedding system?
0x4c56
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(struct
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 == NULL testing
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_stdio.c
