> > 'peek' implements an opcode which can look ahead at an arbitrary number of > > bytes in a IO stream, but does not remove the bytes from the stream in the > > process. > > > [...] > > I have some question though: > > - what if peek wants to look beyond current buffered limits
Yes - at present it only looks up to the maximum size of the IO buffer (which on my machine was 8192 byte). If a request is made to return more than that size, it just returns the maximum buffer size. Since this is my first foray out of PASM and into the actual Parrot C internals, I was still in the process of figuring out what I should be touching, and where it was located. In this case, I wasn't certain if it was possible (or desirable) to be reading past the IO buffer, and if so, where/how I should be allocating and saving further reads on the stream. (That being said, if someone would like to give me a nudge in the right direction, I'm more than happy to do the work of making it happen the right way.) :) > - what are the guarantees of peek's result (AFAIK 1 byte for the stream > layer if ungetc() is available) - what else? > - don't other layers need adjustment if a new layer function is > added? I'm assuming that these both are related to non-buffered input? (If not, then I'm not entirely certain what you mean...) > - did you miss appending all the tests ;) Ummm, most likely. (And I'll have a patch to fix that shortly.) :)
