access permissions in 1003.1

[Sean Eric Fagan]

Submitted-by: sef at kithrup.COM (Sean Eric Fagan)

In article <1991Jun4.221021.26605 at uunet.uu.net> mib at geech.gnu.ai.mit.edu (Michael I Bushnell) writes:
>Given the _POSIX_SOURCE feature test macro, OS designers can load all
>they want in, and turn it off only when _POSIX_SOURCE is defined.  

That doesn't do everything.  Yes, it's possible to come up with a system
that is not only backwards compatible, but also provides full ANSI and/or
POSIX compliance (although it is not possible, necessarily, to mix old and
new).

Problems encountered:  namespace (have to get rid of everthing not defined
by ANSI for ANSI-only, everything not defined by POSIX for POSIX, and yet
have to worry about old binaries, as well as sources, that may rely on such
things [_iob was my favorite example, although there were several like items
in libc that we had to worry a lot about]); different semantics for things
of the same name (more an issue for section 1 and .2 compliance; things like
df and du have portable definitions under POSIX, which may or may not be
different from what old shell scripts expected).  One POSIX "optional"
feature, required by FIPS, was no-truncate; that is, if a filename exceeded
the maximum name length for the filesystem, return ENAMETOOLONG.  Do you
know how many programs out there are written to generate *unique* names in
14 characters or less, but still will try to create names with *more* than
14 characters?  B News, for example, I believe.

Again, yes, it's possible to get around all of these.  By having three
seperate libraries and header files (old, ansi, and posix).  By having two
sets of command trees (/old and /posix; e.g., /old/bin/df and
/posix/bin/df).  By defining bits in the executable's header to indicate
whether new features are to be used or not.  (Incidently, uSoft did that,
apparantly, with the OS/2 HPFS [high performance file system]:  older
programs which do not have the correct bit set in the header will not even
*see* the longer filenames.  I think this is wrong.  Just MHO, though 8-).)

>I'm
>writing a Posix compliant system which will also be 4.4BSD compatable;
>I know whereof I speak.

And I helped implement a POSIX-ANSI-and-X/Open-compliant-yet-backwards-
compatible system (OS, commands, and devsys) for a major vendor.  I also
know whereof I speak.  Many people reading this group can say the same
thing; most of them can probably come up with their own horror stories.  4.4
was intended to be largely POSIX compliant in the first place, and BSD
places less concern on backwards compatibility than commercial vendords do
(SCO, for example, can still execute, *and develop for*, XENIX/XT binaries;
can a BSD system say the same about BSD 4.1?).  Does this mean that SCO is
"better" than CSRG?  No, I didn't say that.  CSRG was able to come up with a
much better system, in many ways (including size, a personal peeve 8-)), and
most of their "customers" have sources anyway.  But the problems commercial
vendors have are very *real* problems.

At this point, I'm curious how SunOS did:  is it still able to run binaries
from 5, 10 years ago, without modification?  Can it still take object
modules from that long ago, and link them in with current libraries?  (Some
third-party people ship modules, and let the customer link them with
customized pieces, for example.)

-- 
Sean Eric Fagan  | "I made the universe, but please don't blame me for it;
sef at kithrup.COM  |  I had a bellyache at the time."
-----------------+           -- The Turtle (Stephen King, _It_)
Any opinions expressed are my own, and generally unpopular with others.


Volume-Number: Volume 23, Number 87