Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.unix.wizards
Subject: Re: Symbolic Links
Message-ID: <6366@brl-smoke.ARPA>
Date: Sat, 29-Aug-87 19:57:09 EDT
Article-I.D.: brl-smok.6366
Posted: Sat Aug 29 19:57:09 1987
Date-Received: Sun, 30-Aug-87 10:03:43 EDT
References: <8731@brl-adm.ARPA> <2789@ulysses.homer.nj.att.com> <1781@munnari.oz> <8195@mimsy.UUCP> <586@murphy.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 46

In article <586@murphy.UUCP> dave@murphy.UUCP (Dave Cornutt) writes:
>Do it on a per-process basis...

As one of the principal developers of dual-universe UNIXes,
perhaps it is appropriate for me to comment on this.  Dual
interpretations are a pain in the donkey!  Select a general
enough interpretation and stick with it; don't make anything
that doesn't have to be, dependent on user whims.  For an
example of the dangers, consider the attempt Berkeley made
to cater to non-restart of slow I/O system calls after return
from a signal handler in 4.3BSD as originally distributed.
The bit SV_INTERRUPT in the sv_flags of the struct sigvec
was supposed to control this behavior.  Unfortunately, it
was not reset upon an exec(), so if ANY process enabled
non-restart, all descendants acted that way too.  Of course,
the descendant processes were written assuming the default
4.3BSD restart of system calls, so things like our EMACS
editor broke horribly when run from a System V shell.  The
moral is, too many options on how the OS behaves is a hazard.

POSIX (1003.1) has shown an annoying tendency recently to not
specify behavior that differs between 4BSD and SysV.  I've
shown that practically ANY behavior can be emulated, given
general enough kernel support.  It is a disservice to
application programmers to waffle on the interface specs so
that the programmer cannot count on reasonable default behavior.
Providing facilities using #ifdef or run-time interrogation
to determine which of several possible behaviors actually
will be obtained is HORRIBLE -- that leaves us no better off
than we were without POSIX!  The point of a STANDARD is to
SPECIFY these things, not to force the programmer to probe
in order to find them out.  I think what's happened is that
the vendors of existing systems have decided they want
"POSIX" to be just a label they can stamp on their current
product for marketing reasons, without having to do any real
work.  If the Final Use POSIX 1003.1 standard is not better
in this regard, I'm going to be agitating AGAINST its
adoption for Federal procurement specification, because as
a developer of portable applications, I need a stronger
specification than this waffling gives me.  Since the only
practical alternative is the SVID, it behooves BSD-based
vendors to cooperate in providing common, definite behavior
even though it means having to provide a compatibility
library for existing BSD-specific applications.  (I don't
see any alternative to that anyway, if they're going to also
conform to X3.159-198x (ANSI C).)