PIO_eof
Vladimir Lipsky
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 prohibited in Parrot embedding system?
0x4c56
Melvin Smith
>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
In PIO_open the ParrotIO object never gets created if there is
an error condition.
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
Currently it isn't prohibitied. That is the only way to detect an error
from PIO_open* at this time.
If someone convinces me that it is better to return a ParrotIO object
with error flags set rather than skip creating it, I might consider it.
It is probably more likely that we simply need documentation.
-Melvin
Vladimir Lipsky
> 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
Juergen Boemmels
> 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, io_unix.c nor io_win32.c
>
> In PIO_open the ParrotIO object never gets created if there is
> an error condition.
But PIO_open returns a valid IO-PMC which just has a NULL in its data
segment. Maybe it should return PMCNULL if the open fails.
BTW: None of the PIO_* functions check if the incoming PMC is really a IO-PMC.
Maybe its a good idea to add glib-like return_if_fail like assertion
in the beginning of the functions. This reduces the speed but makes
debugging easier. Toughts?
> 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
>
> Currently it isn't prohibitied. That is the only way to detect an error
> from PIO_open* at this time.
No, even that is wrong. PIO_open returns a PMC with NULL data.
So the test would be PMC_data(io) == NULL, but I think the better idea
is to return PMCNULL.
> If someone convinces me that it is better to return a ParrotIO object
> with error flags set rather than skip creating it, I might consider it.
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 parrot_io_t) instead of sizeof(PMC). I don't know if
something like that is already possible. Furthermore there are issues
with morph: You simply just can't morph another object to an IO
without reallocation.
> It is probably more likely that we simply need documentation.
Sure, documentation is missing.
boe
--
Juergen Boemmels boem...@physik.uni-kl.de
Fachbereich Physik Tel: ++49-(0)631-205-2817
Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906
PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Melvin Smith
>Melvin Smith <mrjol...@mindspring.com> writes:
> > In PIO_open the ParrotIO object never gets created if there is
> > an error condition.
>
>But PIO_open returns a valid IO-PMC which just has a NULL in its data
>segment. Maybe it should return PMCNULL if the open fails.
It should. I was working on other things so I didn't loot too close.
>BTW: None of the PIO_* functions check if the incoming PMC is really a IO-PMC.
>Maybe its a good idea to add glib-like return_if_fail like assertion
>in the beginning of the functions. This reduces the 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" testing prohibited in Parrot embedding system?
> > >
> > >0x4c56
> >
> > Currently it isn't prohibitied. That is the only way to detect an error
> > from PIO_open* at this time.
>
>No, even that is wrong. PIO_open returns a PMC with NULL data.
>So the test would be PMC_data(io) == NULL, but I think the better idea
>is to return PMCNULL.
When I said "io" I meant ParrotIO, not PMC, but I see how it gets confusing.
I think PMCNULL should be NULL for all PMCs, at least for user visible APIs.
PMC internals (hash/array implementations, etc) don't necessarily have to use
the convention, but I know my time has been better spent now that we get
"NULL PMC" exceptions rather than seg faults. It'll just be a slow process
to guarantee all of Parrot conforms.
> > If someone convinces me that it is better to return a ParrotIO object
> > with error flags set rather than skip creating it, I might consider it.
>
>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 parrot_io_t) instead of sizeof(PMC). I don't know if
>something like that is already possible. Furthermore there are issues
Yes, I'm pretty sure it is possible with current API.
I'm occupied elsewhere with IMCC, classes and Cola rewrite, sorry I
haven't been more help on IO.
I'm normally ok with what you suggest, so have a go at it
if you get free time, since you are the active IO maintainer. If you commit
something that doesn't work well, we just change it, no harm done.
Functional-Kludge is always better than Non-Existence in my book.
-Melvin
Leopold Toetsch
> 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 parrot_io_t) instead of sizeof(PMC). I don't know if
> something like that is already possible.
You can't use such an object instead of an PMC. But you can hang it onto
the PMC_data pointer. Hash or List do the same. You just have to create
the sized pool entry in class_init() and mark it properly.
> boe
leo