[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