Melvin Smith <[EMAIL PROTECTED]> 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
