Ben Rudiak-Gould
First of all, I don't think any OS shares file pointers between processes.
Unix does. It's because shared files are usually stdin/stdout/stderr (I mean that they are visible as stdin/stdout/stderr, rather than about their nature as terminals - they may be regular files), which are usually accessed sequentially without seeking. Quite often they are not seekable at all (terminals or pipes), which means that they behave as if the file pointer was always positioned at the end (for writing) or beginning (for reading) and shared. If they are seekable, the position is shared so you can redirect I/O to a process running subprograms.
Otherwise it would be practically impossible to safely use an inherited filehandle via any API.
Pipes are not seekable and always behave as if the position is shared. It doesn't make them impossible to safely inherit. They are inherited on fork because they are anonymous objects, so it's the only way to connect them; after fork most programs close the reading end in one of the processes and the writing end in the other. It's rare that two processes read from the same pipe or write to the same pipe. If they do, one of them is usually a helper program started by the other, and the other waits for the helper to finish. If you want two processes to access the same file indepenently, pass a file name and open it twice.
The file interface in this library is only used for files, which are always seekable (by definition).
What do you mean by files? What you get from open() is not always seekable, because it's not always a regular file. The name may refer to a device (whether it's seekable depends on the particular device; block devices are seekable but most character devices are not, e.g. /dev/ttyS0, /dev/lp0 - serial and parallel ports) or to a named pipe (not seekable). -- __("< Marcin Kowalczyk \__/ qrczak@knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/