Perhaps someone with a bit more familiarity with the Parrot IO subsystem
could give me some guidance here. I'm currently trying to get a new
'peek' opcode working, and I'm having difficulties getting the io_unix
layer implemented correctly.
As far as I know, I'd get a call down into the io_unix layer when the
ParrotIO object isn't buffered. What I want to be able to do is to
read()/fread() a character off of the io->fd filedescriptor, copy it into
the buffer, then ungetc() it back onto the stream.
You can't push a character back onto a Unix file descriptor. In order to emulate this for parrot, you'll need some storage hanging off of the ParrotIO structure to store the "pushed back" characters, and then munge the read methods to pull data from here before reading from the real descriptor, if there has been anything pushed back. This is, essentially what the C std. lib. buffered IO API does--the core Unix IO API doesn't provide this functionality. For parrot, I think that we should only do this for the io_buf layer (and maybe the io_stdio layer), which is the buffered IO layer, and already has a buffer which can be used for this purpose. I don't think it's appropriate for the io_unix layer--I see that as a direct wrapper around the Unix API.
Unfortunately, however, ungetc requires a (FILE *), while the ParrotIO object carries around only a raw file descriptor (I think).
Yes, the C std. lib. IO API is a wrapper on top of the core OS IO routines (for Unix or Windows), and we're using the core IO routines to implement our IO functionality, rather than going through an extra layer. (And io_stdio is based on the C std. lib., and I believe is provided so that it can be used on systems for which none of the other base layers is available--non-Unix and non-Windows.)
I've seen some instances where people will cast the raw descriptor to a (FILE *)
I can't imagine where that would ever work. A (FILE *) is a pointer to a struct which stores various bits of data, including the actual file descriptor. A file descriptor is just an integer, and isn't going to be interpretable as a pointer to such a struct--using the core Unix IO API, no such struct will have been created anywhere in memory. So you can't get a FILE* via any sort of casting, at least not on Unix platforms.
however the man page for ungetc warns ominously in its BUGS section that:
It is not advisable to mix calls to input functions from the stdio library with low - level calls to read() for the file descriptor associated with the input stream; the results will be undefined and very probably not what you want.
This is warning about something else. It's saying don't use the C API to do IO on a FILE*, and also use the Unix IO API on the descriptor which is is the fileno() of that FILE*. But even this you wouldn't do by casting--you'd either get the descriptor from the FILE* using fileno(), or use fdopen() to create a FILE* from a descriptor.
But in any event, we don't want to use the C std. lib. IO API inside of the io_unix layer.
That being said, what is the best course for buffering such characters at
the io_unix layer? I apparently am not able to use the standard library
functions to do so (additionally, they only guarantee that you can peek
and replace a single character).
As I said above, I think we'd only want to do this for the io_buf layer, though others may disagree. If we do want to do it at the io_unix layer, then we can just copy down a bunch of code from io_buf, because we will be making the io_unix layer a buffered layer (with the difference being that the buffer would only be populated in the case of pushing back read items, an not during reads).
JEff
