toppin@melpar.UUCP (Doug Toppin) (10/17/89)
Can anyone send me the name, ISBN, publisher, and price of any references on POSIX please? I have been looking for them and have had no luck. I would also be interested in opinions on how difficult it is to port C programs from Unix System V to POSIX. thanks Doug Toppin uunet!melpar!toppin
kannan@babcock.cerc.wvu.wvnet.edu (R. Kannan) (10/19/89)
From article <238@melpar.UUCP>, by toppin@melpar.UUCP (Doug Toppin): > Can anyone send me the name, ISBN, publisher, and price of any > references on POSIX please? > how difficult it is to port C programs from Unix System V to POSIX. > thanks Could you please summarize the replies. Thank you very much USPOST R.Kannan Drawer 2000 CERC, West Virginia University, Morgantown, WV 26505 Phone 304-293-7536 Fax 304-293-7541 E-mail kannan@cerc.wvu.wvnet.edu ---kannan
suitti@haddock.ima.isc.com (Stephen Uitti) (10/21/89)
In article <238@melpar.UUCP> toppin@melpar.UUCP (Doug Toppin) writes: >Can anyone send me the name, ISBN, publisher, and price of any >references on POSIX please? I have been looking for them and >have had no luck. I would also be interested in opinions on >how difficult it is to port C programs from Unix System V to POSIX. >thanks >Doug Toppin >uunet!melpar!toppin I'd send mail, but... The "Green book" is here in front of me. IEEE Standard Portable Operating System Interface (That's what POSIX is) for Computer Environments (note: not just UNIX - though it looks like it) POSIX P1003.1 Published by The Institute of Electrical and Electronics Engineers, Inc. I haven't a clue how i got my copy, but, under "related standards", it says: IEEE & ANSI/IEEE standards can be ordered from Publication Sales IEEE Service Center P.O. Box 1331 445 Hoes Lane Piscataway, NJ 08854-1331 (201) 981-0060 I ported a few of my old programs to POSIX while working on the INTERACTIVE 386/ix POSIX project (due to be released soon, as 386/ix 2.2, as i understand these things). Most of the programs I've ever written compile & work without modification. Granted, most of the stuff i've written avoids nonportable OS constructs, as early on, my code had to port back & forth between a PDP-11 running 2.8 BSD and a Vax running 4.1BSD or 4.2BSD. I have more trouble porting stuff from SysV to BSD or BSD to SysV than from either to POSIX. For 386/ix, a SysV R3.2 based system, POSIX required some new system calls (strictly speaking, POSIX doesn't require anything to be a syscall, since everything is a "function", and can be implemented as a library call or syscall): fpathconf, getgroups, pathconf, rename, setgroups, setpgid, setsid, sigaction, sigpending, sigprocmask, sysconf, waitpid. The *conf routines allow you to ask the running system what many limits are. How many multiple groups, simultaneous open files, etc. Setgroups (not strictly POSIX) and getgroups do multiple groups (initgroups can be implemented on these in a library). setsid, setpgid, waitpid are required for job control. The new signal functions sigaction, sigpending, sigprocmask are real nice. signal() is retained. rename() is for file renames. POSIX does not require every feature to work. However, people who implement POSIX tend to also satisfy the FIPS 151-1 document. The FIPS document states what features which are optional in POSIX that are required. It requires Job Control and Multiple groups (at least 8). It requires other useful stuff: The group of new files is that of the parent directory (as BSD). It narrows the semantics of read() & write() with interrupts. Some system calls have their semantics changed a little. Signals work better (they can't get reset on you). For the most part, semantics are simply codified rather than changed. The tty driver was an exception. Neither SysV or BSD were acceptable. Most library calls can be used as if they were SysV or BSD. One problem I've run into: In POSIX, the directory programs use struct dirent, rather than the BSD struct direct. 4.2 BSD systems should not have done this, as it causes a name conflict when implementing ndir. SysV.3 uses struct dirent. I now use "dirent", with some easier magic for 4.2 based systems. I've been using directory or directory emulation routines since libndir & ndir.h were released just prior to 4.1c BSD was available. The abstraction should have been there sooner. Note that i haven't been using a POSIX system with an ANSI compiler. I have ported much of my stuff to Turbo C and Lightspeed C on my home computers. These are close to ANSI, in the sense that they do prototypes and some of the other new stuff. I've just gotten gcc up on my POSIX '386, and had some problem with a variadic function. The code I was attempting to compile wasn't mine, and i didn't have time to look into it. I don't expect any really big problems (insurmountable). Stephen.
dal8372@cec2.wustl.edu (David A. Luther) (10/23/89)
Sorry!