On Fri, Mar 03, 2006 at 11:27:05AM -0800, Allison Randal wrote:
=item *
C<readline> retrieves a single line from a stream into a string. Calling
C<readline> flags the stream as operating in line-buffer mode (see
C<pioctl> below). Lines are truncated at 64K.
Is there a fundamental need for a hard hard limit? I can see that it would
be flexible to allow the stream to set this value, but it doesn't seem very
perlish to deny programmer sufficient rope to hang themselves if they so
wish.
=item *
C<getfd> retrieves the UNIX integer file descriptor of a stream object,
or 0 if it doesn't have an integer file descriptor. [Maybe -1 would be a
better code for "undefined", since standard input is 0.]
I think that this has to be -1, as in an embedded system (such as under
Apache) standard input is often closed, and so descriptor 0 can be re-used.
=item *
C<stat> retrieves information about a file on the filesystem. It takes a
string filename or an integer argument of a UNIX file descriptor, and an
integer flag for the type of information requested. It returns an
integer containing the requested information. The following constants
are defined for the type of information requested (see
F<runtime/parrot/include/stat.pasm>):
To me it seems that stat should also be able to take a PMC representing an
open parrot file handle. I assume that systems exist where we'll be
layering Parrot IO onto underlying OS IO, where the OS uses tokens other
than integers for its files. For example pointers, if miniparrot is built
by layering Parrot IO onto C's stdio.
3 STAT_ISDEV
Whether the file is a device such as a terminal or a disk.
Don't we need to get more flexible than this?
At least file/terminal/socket/character special/block special/fifo/symlink/door
Nicholas Clark
