motives for AT&T, etc (was re: att & osf)

[Bob Lenk]

> I disagree. It is much easier to write portable software in SVID
> than it is to do it in POSIX. POSIX left too many features optional
> and implementation dependent.

I've heard that a lot, but I have yet to see evidence that it's true.
Yes, the words "option" and "implementation defined" appear much more
in POSIX than in the SVID.  Conversely, the SVID has various "extensions"
which are the same as "options".  Also, I think that the greatest
number of "implementation defined" areas are areas that the SVID simply
ignores.

Now, let's go through the explicit options in POSIX Draft 12.3 (since
they're fairly easy to find) and see how POSIX and SVID compare as
portability aids:

	NGROUPS_MAX (BSD multiple groups)

	SVID effectively has this limit set to zero, meaning that it
	omits a feature.  It's straightforward to program portably for
	any value of this limit.  Admittedly it's not quite as simple as
	programming for a system without the feature, but the additional
	sophistication should be no problem for the type of application
	that would be interested.  Of course various SVID-conformant
	system provide ways to get this BSD functionality in some type
	of non-SVID environment; the SVID-based application just has no
	way to deal with this.

	_POSIX_JOB_CONTROL

	SVID simply doesn't provide the feature.  A POSIX application
	that wants to be job control dumb is similarly unaffected.

	_POSIX_SAVED_IDS (SVID saved-set-user/group ID feature)

	This is a case where SVID simply does provide the feature.
	That does make programming easier (it would also help if
	SVID and the SysV implementation agreed).

	_POSIX_CHOWN_RESTRICTED (can non-superuser chown files?)

	SVID permits arbitrary chown'ing, which does make portable
	programming easier.  On the other hand, too many people think
	this is a severe security hole to accept it.  As a result,
	there are vendors whose systems conform to SVID except for this
	(and perhaps one or two other small things).  Thus portability
	is eased in a smaller universe.  In reality, a portable program
	that simply doesn't use chown (under the assumption that it
	might not work) is no problem to write.

	_POSIX_NO_TRUNC (is too long filename truncated or does it give error?)

	This is a rather messy situation to deal with in POSIX.  SVID
	is totally silent on the semantics here.  The diversity thus
	exists there too, but the application has no handle on it
	at all (as opposed to a clumsy handle in POSIX).

	_POSIX_VDISABLE (is there a setting to disable special tty characters?)

	SVID takes the side that there is no such special character.
	This makes portable programming simpler in two cases: (1) where
	the application wants to set the special character (eg. ERASE)
	to some bizarre value (like '\377') that the system chose as
	the disable value, and (2) where the application wants to
	emulate the line discipline.  Conversely, it does not allow
	disabling the special character function.

I'll also look at two of the most commonly mentioned explicit options from
Draft 12, which are now implicit in 12.3 (note that a number of others
are no longer options, either explicit or implicit):

	_POSIX_DIR_DOTS	(are the . and .. entries visible via readdir()?)

	SVID is totally silent on the semantics here.  An application can
	easily be written to ignore these entries if it sees them.  POSIX
	explains this.

	_POSIX_GROUP_PARENT (is new file's group from eff. uid of creating
			     process or group ID of parent directory?)

	SVID goes with the effective uid, making things more
	predictable.  A portable POSIX program can always get these
	semantics by chown'ing the new file after creation, which is a
	little more work, if it cares.

In conclusion, I don't see that the SVID makes life all that much easier,
or that the POSIX options are without justification.

There's a separate argument that SVID covers more.  That's very true if
you compare it to 1003.1.  I doubt it will be true in comparison to the
standards eventually covered by the 1003.0 guide.  SVID certainly has a
head start, and is very useful because of that.  Its existence is very
useful for the development of 1003.1 and other standards.  But SVID is a
different animal than POSIX.  SVID is a specification of the interface
to a specific operating system.  While it can be applied both to ports
of that system and to separate implementations conforming to the same
interface, its heritage is definitely a single implementation.  As such,
one would expect it to permit less divergence, and to apply to fewer
implementations.

Apologies for the length of this posting.

		Bob Lenk
		hplabs!hpfcla!rml
		rml%hpfcla at hplabs.hp.com