getcwd() and friends.

[aglew at xenurus.gould.com]

>In article <4523 at psuvax1.cs.psu.edu> schwartz at shire.cs.psu.edu (Scott Schwartz) writes:
>: I think we need a good dose of Multics: Reading the time should be
>: equivalent to accessing an object in virtual memory.  In fact, the
>: whole operating system system should behave like that, filesystem,
>: system calls, and so on.
>
>Ack, NO! All we need is one rogue pointer and almost ANYTHING can
>happen!
>
>That notion is attractive, but the separation produced by having
>system calls means that a much smaller class of errors is likely to
>do random things to your operating environment.
>
>---
>Bill                            { uunet | novavax } !twwells!bill


Going further - performing all operations via a limited set of operations
on files (augmented by ioctls) is defining the interface via DATA STRUCTURES.
System calls, etc., are a functional interface.

To repeat, there are two ways of defining interfaces: via DATA STRUCTURES,
and via FUNCTIONS (or operations, etc.).  Functional interfaces are more 
flexible - you can put a wrapper around a function to include augmented
functionality.  You can't do this to data structures unless you can get
a trap on access.
    Eg. say we have a simple data structure, a stack implemented in an array.
You can define it as "here is the array, and a current pointer variable - 
you add something to the stack by putting it in the array and incrementing
the variable". Or you can define it via abstract operations PUSH and POP.
Guess which is easier to change implementation.

Adding functionality by read/write calls is sort of semi-functional --
it has a functional interface, but all the crucial detail is in the
data structures that are read/written.  If you do things that way, at the
very least provide a functional approach to dissecting the data structures
(not a data structure layout).

Andy "Krazy" Glew,  Motorola MCD,    	    	    aglew at urbana.mcd.mot.com
1101 E. University, Urbana, IL 61801, USA.          uunet!uiucdcs!mcdurb!aglew