rbutterworth@watmath.waterloo.edu (Ray Butterworth) (08/18/89)
In article <5692@ficc.uu.net>, peter@ficc.uu.net (Peter da Silva) writes: > Subject: Re: ReadKey like Function in C > I redirected this back to comp.std.c, because I'm really not interested > in the POSIX standard here. The main reason POSIX comes up in this group > is because of holes in the ANSI C standard. Many of them are reasonably > brushed aside as outside the scope of the standard, but then the POSIX > standard is referred to as something that will cover them... and as this > message (I hope) shows, that just ain't so... > > I expressed dismay that POSIX mandated fork(): > ... > But this rules out POSIX support for a wide variety of operating systems. ^^^^^^^^^^^^^^^^^ But POSIX in effect IS an operating system. ANSI C defines a minimal compiler language that can reasonably be implemented on a variety of operating systems. If a feature is very OS-dependent, it doesn't belong in that standard. ANSI C can't mandate such functions as "get one character from the terminal" or "turn on this file's setgid bit" without making the compiler useless for a significant number of operating systems. POSIX defines a minimal (well not really) operating system that can reasonably be implemented on a variety of different hardware configurations. If a feature is very hardware specific, it doesn't belong in that standard. POSIX can't mandate such functions as ascbcd("ascii string", &bcdstring), which converts the ascii characters to 6-bit BCD characters and inserts them 6 per 36-bit word into the bcdstring target, without making the OS useless on a significant number of machine architectures. I use such a machine, but I wouldn't expect 36-bit words to be required in order to support a portable operating system, much less be required to support a portable compiler. If I am writing something that relies on 36-bit words, I am writing something very machine-specific and if I expect any support for it, it would be from a machine-specific library, not from one mandated by ANSI C or by POSIX. The point is, if you are trying to do something that is OS-specific, you shouldn't be asking a portable compiler to provide the functionality, and if you are trying to do something that is hardware-specific, you shouldn't be asking a portable operating system to provide the functionality. setgid is very OS dependent; if you want to talk about that, it belongs in UNIX or POSIX discussions, not in comp.std.c. 36-bit words are very hardware dependent; if you want to talk about that, it belongs in comp.arch.thirtysix or comp.dps8, not in comp.std.c or comp.std.unix.
peter@ficc.uu.net (Peter da Silva) (08/18/89)
In article <28442@watmath.waterloo.edu>, rbutterworth@watmath.waterloo.edu (Ray Butterworth) writes:
[POSIX is an operating system, and not relevant to the C language standard]
That's basically what I said. The problem is that a frequent response
to "why isn't X in X3J11" is "Look in P1003.*, it's in there". The fact
that something is in POSIX isn't really relevant. POSIX is not intended
to fill in he gaps in the C standard. It's an OS standard, not an OS
interface standard (well, it is that too... just not a very portable one).
If we want an interface standard that goes beyond X3J11 without mandating
UNIX, we're going to have to make one ourselves. POSIX is a good starting
point and source of ideas, but no more than that.
--
Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation.
Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-'
"Optimization is not some mystical state of grace, it is an intricate act U
of human labor which carries real costs and real risks." -- Tom Neffgwyn@smoke.BRL.MIL (Doug Gwyn) (08/19/89)
In article <5780@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >POSIX is not intended to fill in he gaps in the C standard. No, but that's not the point. Recall that most C implementations have provided open(), read(), etc. in their libraries even though they run on operating systems quite unlike UNIX. The UNIX C library served as a de facto standard for such facilities. Now that there is an official standard for UNIX-like systems, it should be expected to replace UNIX in this role. The main advantage of POSIX over UNIX for this is that it provides exactly one way to do such things as disabling echo mode, whereas the existence of several different UNIX versions made it harder to use UNIX for a model for such operations. Nobody is seriously suggesting that all of POSIX has to be implemented in a non-UNIX environment for it to provide a good guide for just those facilities that CAN be readily emulated.
peter@ficc.uu.net (Peter da Silva) (08/20/89)
In article <10785@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn) writes: > Nobody is seriously suggesting that all of POSIX has to be implemented > in a non-UNIX environment for it to provide a good guide for just those > facilities that CAN be readily emulated. Well, perhaps there should be some attention given to what a good POSIX subset should be, and what that subset should do for those features of POSIX that are not readily implementable. The number one problem here is what to do about fork(), and the number two is what to do about pipes. Most of the uses of fork() can be satisfied by the following function: spawn(cmdlin, in, out, wait) char *cmdlin; /* Program to execute */ int in, out; /* File descriptors to use for input and output */ int wait; /* A boolean flag indicating whether we should wait for the program to complete. If the flag is *true*, spawn will return an id to wait on. If the flag is *false*, spawn will wait for the command to complete, and return the exit status of the command (8 bits). If the system can't fulfil the request, spawn will return an error code. */ About the only operating system I'm familiar with that can't implement this function is CP/M, or its immediate predecessor Isis. Most uses of pipe() can be handled by using popen(). The one big one that can't is setting up a filter. Anyone have any ideas? This may be even harder to solve. -- Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation. Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-' "Optimization is not some mystical state of grace, it is an intricate act U of human labor which carries real costs and real risks." -- Tom Neff
jfh@rpp386.Dallas.TX.US (John F. Haugh II) (08/21/89)
In article <5795@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >Most of the uses of fork() can be satisfied by the following function: Well, every program which can be written using spawn() can also be written using fork() and exec(). Any just about any system worth writing an operating system for of the scope of POSIX is going to have the hardware to do memory management. Any system without MMU hardware probably lacks sufficient address space or commercial interest to be worth spending hundreds of millions of dollars developing software for. And THAT is the real reason. What good is an operating system for machines that don't generate gobs of revenue, or that no one wants to buy because they are overly restrictive? As Dennis Ritchie says, if you want PL/1, you know where to look. -- John F. Haugh II +-Quote of the month club: ------------ VoiceNet: (512) 832-8832 Data: -8835 | Speaking of Netnews Administration: InterNet: jfh@rpp386.cactus.org | "If Bill Vajk can do it, anyone can" UUCPNet: {texbell|bigtex}!rpp386!jfh +--------- -- Patricia O Tuama-----
peter@ficc.uu.net (Peter da Silva) (08/22/89)
In article <16922@rpp386.Dallas.TX.US>, jfh@rpp386.Dallas.TX.US (John F. Haugh II) writes: > In article <5795@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: > >Most of the uses of fork() can be satisfied by the following function: > Well, every program which can be written using spawn() can also be > written using fork() and exec(). But not every programming environment can support fork/exec. Most can support spawn(). > Any just about any system worth writing an operating system for of the > scope of POSIX is going to have the hardware to do memory management. Who's talking about operating systems, hey? This is comp.std.c, a group for the discussion of C language standards. I'm trying to point out a gap in the set of current C language standards... a portable O/S interface standard. Something between X3J11 and POSIX. > Any system without MMU hardware probably lacks sufficient address space > or commercial interest to be worth spending hundreds of millions of > dollars developing software for. What, you mean like the IBM-PC? > And THAT is the real reason. What > good is an operating system for machines that don't generate gobs of > revenue, or that no one wants to buy because they are overly restrictive? Most people writing C programs today are working in an environment that will never support POSIX. They are busily writing many very good programs that will never be easily ported to POSIX environments because there is no standard for the sorts of things they want to do. I'm trying to suggest ways to fill in the gaps. Standardising the syntax and semantics of spawn() (under whatever name) is one thing that will help. -- Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation. Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-' "The security biz is subtle, you have to pick your trade-offs carefully." U -- Barry Shein