On Fri, Mar 03, 2006 at 11:27:05AM -0800, Allison Randal wrote: > What I need from you all is comments. What's missing? What's > inaccurate? What's accurate for the current state of Parrot, but is > something you always intended to write out later? What thoughts have > you had on how the I/O subsystem should work? All contributions > cheerfully welcomed, from a single sentence to several pages of text.
=item * C<seek> sets the current file position of a stream object to an integer byte offset from an integer starting position (0 for the start of the file, 1 for the current position, and 2 for the end of the file). =item * C<tell> retrieves the current file position of a stream object. It also has a 64-bit variant that returns the byte offset as two integers (one for the first 32 bits of the 64-bit offset, and one for the second 32 bits). Shouldn't there be a 64-bit variant of seek? In fact, one doesn't need a tell opcode at all, given that seeking 0 from the current position is tell. (Although in turn that could function as a test for "is this file is seekable?" What does seek return on an unseekable file? What does tell return? IIRC sfio returned the number of bytes read (or written) for an unseekable file. Is that useful? Presumably seek() on a buffered stream discards any written but not flushed data. Mmm. Flush opcode needed for buffered streams? Nicholas Clark
