[ANSI-Smalltalk] Smalltalk file streams
Richard O'Keefe
ok at cs.otago.ac.nz
Fri Oct 17 07:02:53 BST 2008
>
> I think that both #close and #flush should live in <Stream>,
> possibly as
> no-ops. Most implementations do that.
Agree.
>
>
>> This leaves the issue of /dev/tty, ptys, /dev/[u]random, a whole
>> bunch of things in /proc, and so on, exactly where they stood
>> before: you can open then using FileStream, you can read from
>> them, but they have operations in their interface that they
>> CANNOT implement. There needs to be a standard way to deal with
>> this.
>
> For something like #position, exceptions are the solution. But if I
> ask
> for the contents of /dev/urandom, I have a problem, the system should
> not be responsible for me doing something insane.
In general, providing #contents requires seeking.
You should be able to provide #contents for precisely
the file system objects that support #position:,
provided they are not too big, and provided you have
read access.
As it happens, /dev/urandom on Mac OS X does claim to
support seeking, but fseek(f, 0, SEEK_END) followed by
ftell(f), where f is open on /dev/urandom, gives the
answer 0. So determining the size that way would result
in empty contents.
The system is not responsible for doing something insane,
I am. But THE SYSTEM IS RESPONSIBLE FOR RESPONDING SANELY.
The "I" is ambiguous here.
User A types a string at program X.
Program X transforms it and passes it to program Y.
Program Y transforms it and passes it to system service S,
which is defined to accept all values.
It so happens that the string that S gets doesn't
make much sense. But who is "I" here?
A? X? Y?
As a silly example, suppose your program tries to read
configuration data from ~/.paolorc, and unbeknownst to
you, a cut and paste error made by a system administrator
yesterday resulted in my ~/.paolorc being overwritten with
a symbolic link to /dev/fd/0.
- Is your program to blame for not checking that the file
is a disc file, as well as being an existing readable file?
- Is the person between the chair and the keyboard to blame?
But _I_ did nothing wrong...
Standards should provide the minimal tools needed to
write programs that can respond sanely.
More information about the ANSI-Smalltalk
mailing list