mike@whutt.UUCP (BALDWIN) (08/05/88)
> > ... Do remember that there have already been two releases of the SVID, > > and nobody seriously believes there won't be more. > >There have not been two versions of the SVID, there have been volumes added > >to the SVID to cover developments in various areas, particularly networking. > If there haven't been two versions of the SVID, why does my copy call itself > "Issue 2" and list at the back a lot of differences between Issues 1 and 2? The differences are typically clarifications or bug fixes to the documentation, not changes in functionality. For instance, CREAT(BA_OS) in Issue 1 stated that the file mode bits were ANDed with the umask. The changes section in Issue 2 states that it should be "ANDed with the complement of the umask". I don't think fixing documentation deserves to be called a different standard. Please name something useful that has changed from Issue 1 to 2. > The SVID WILL BE REISSUED as necessary to reflect developments > in the System V Interface. Of course! The SVID is updates more or less at each major release. > As I have found to my cost, Issue 2 is not always a reliable guide to V.3. What things are not accurate? -- Michael Scott Baldwin research!mike attmail!mike mike@att.com AT&T Bell Laboratories +1 201 386 3052
ok@quintus.uucp (Richard A. O'Keefe) (08/11/88)
In article <3716@whutt.UUCP> mike@whutt.UUCP (BALDWIN) writes: >> > ... Do remember that there have already been two releases of the SVID, >I don't think fixing documentation deserves to be called a different standard. >Please name something useful that has changed from Issue 1 to 2. Henry Spencer said that "there have already been two releases of the SVID". This was denied by someone whose name I forget, posting from AT&T. I pointed out that Henry Spencer is correct according to the SVID itself. I never claimed that this was a bad thing. My word, I _like_ the Future Directions sections in the SVID, and wish more O/S vendors did that. I don't know whether you'd count the behaviour of getcwd() when passed a NULL argument as useful; but it is documented V.2 functionality which I have known programs to use and it was dropped in SVID 2. There are a couple of other documented changes worth noting, and then there are the differences they didn't notice. (Find them yourself.) >> As I have found to my cost, Issue 2 is not always a reliable guide to V.3. >What things are not accurate? To say that SVID 2 is not a reliable guide to V.3 is not to say that anything in it is inaccurate. SVID 2 claims only to describe V.1 and V.2. If you really want to know about the differences between SVID 2 and V.3, read the V.3 release notes. The changes aren't just additions & enhancements. The lesson is: never assume that code which worked in release X.Y will work in release X.Y+1, always read the release notes *first*. Can I please get out of this topic now? I'm sorry I ever stepped in.
gwyn@smoke.ARPA (Doug Gwyn ) (08/12/88)
For the benefit of those whose knowledge about the SVID is limited to what they read in this newsgroup, let me clarify a few points. So far as I am aware, there have been two "issues" of the SVID. An "issue" basically obsoletes the previous issue. However, an Issue in general consists of an open-ended set of individual Volumes published at different times. So far I have three Volumes in Issue 2 of the SVID. Volumes 1 & 2 basically supplanted, then extended, what was in SVID Issue 1. Volume 3 contains interface specs for features introduced after UNIX System V Release 2, plus a few revisions to specs in the earlier volumes. In general, revisions extend the functionality without changing it, or correct technical errors in earlier specs. There have been few significant changes to the interfaces specified in earlier issues/ volumes of the SVID, which is as one would expect -- large changes would cause trouble for existing applications, and riling existing customers is no way to keep their business. For the most part, each new volume has merely introduced additional functionality. The SVID was designed to provide for controlled evolution of the specs, which is necessary to correct problems and track future developments. (The alternative, a "stagnant standard", is of comparatively little value.) The rule was, an impending change would be pre-announced at least three years in advance, and would be flagged in the SVID as such. For example, from the beginning the UNIX "plot" and PWB/Graphics functionality was flagged as obsolescent. (In this particular case, no replacement has appeared!) I'm not sure the 3-year rule has been strictly followed in recent volumes.. Of course, the SVID development has gotten somewhat screwed up by the recent independent development of UNIX "standards" which AT&T will pretty much have to accommodate somehow. For example, there will have to be a considerable revision of the SVID for POSIX compatibility. I don't know if AT&T is planning on starting a new "issue" for that or adding another volume to Issue 2.