A filename is a string.
A pathname is a designator for a file-descriptor: the filename is
-computed as if by NAMESTRING
+computed using the same mechanism as the implementation would
+use to map pathnames to OS filenames internally.
+
+In an implementation that supports pathnames to files on other hosts,
+using mechanisms not available to the underlying OS (for example,
+using an FTP or HTTP client in the Lisp implementation), the effect
+of supplying this interface with a pathname to such a file is undefined.
+
** buffer
-A buffer is an opaque object with accessors BUFFER-START and
-BUFFER-LENGTH, which represents an area of memory that system calls
-may access. A buffer can be created using ALLOCATE-BUFFER or GET-BUFFER.
+A buffer is an opaque object which represents an area of memory that
+system calls may access. It has accessors BUFFER-START and
+BUFFER-LENGTH, and can be created using ALLOCATE-BUFFER or GET-BUFFER.
[ TODO: GET-BUFFER is a silly name. Come up with a better one ]
We do not automatically translate the returned value into "Lispy"
objects - for example, SB-POSIX:OPEN returns a small integer, not a
-stream.
+stream. Exception: boolean-returning functions (or, more commonly,
+macros) do not return a C integer, but instead a lisp boolean [ or
+maybe "true"/"false" in CLtS parlance ]; the rationale behind this
+exception is that there is nothing that can be meaningfully done with
+the boolean except test for truth or falsity -- it cannot be passed
+meaningfully to other POSIX functions.
[ Rationale: This is an interface to POSIX, not a high-level interface
that uses POSIX, and many people using it will actually want to mess
The use of DEFINE-CALL macro in interface.lisp should be obvious from
the existing examples, if less so from the macroexpansion
+
+
+
+
+GC issues
+
+buffers that refer to C stuff are probably not movable by GC anyway
+
+a buffer that refers to a Lisp object may have trouble if the Lisp
+object is moved
+
+