home *** CD-ROM | disk | FTP | other *** search
- Submitted-by: sef@kithrup.COM (Sean Eric Fagan)
-
- In article <1991Jun12.235808.20822@uunet.uu.net> mib@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@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
-
-