access permissions in 1003.1

Sean Eric Fagan sef at kithrup.COM
Fri Jun 14 04:38:47 AEST 1991


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

In article <1991Jun12.235808.20822 at uunet.uu.net> mib at geech.gnu.ai.mit.edu (Michael I Bushnell) writes:
>HP is *already* claiming Posix compliance, and you say one of the
>solutions "will likely be used".  *That* is precisely the problem.

No, that is not the problem.  I do not work for HP, nor have I ever in the
past.  As far as I know, HP solved the problem quite nicely.  For the
company I was working for, which was *not* HP, I and one other person spent
a few weeks looking into the name-space pollution problem, how to solve it,
and what it would affect in terms of compatibility with old programs and
binaries.

Another poster asks what the two "fairly obvious" methods are.  One is to have
an "ansi-only" mode, a "posix-only" mode, and a "normal" mode, probably
toggled by command-line switches.  Each "mode" would have its own
header-file tree assosciated with it, with only the header-files defined by
that standard (normal would, of course, have everything), as well as a
special library and startup-file.

The other way is a bit harder, but allows backwards-compatibility to work
more easily (at least with supposedly-compliant programs).  Essentially, you
have all "illegal" symbols be "safe" (__select, for example).  All library
routines are written to use the __ names; then, you have the linker accept
an option that tells it to try to ignore the leading __ if there are
unresolved externals.  You still need header-file work, of course, but that
does help the name-pollution problem.  If I remember correctly, both HP and
AT&T did something similar.

-- 
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 24, Number 3



More information about the Comp.std.unix mailing list