Xref: utzoo comp.std.c:2184 comp.lang.c:23996 Path: utzoo!attcan!uunet!nuchat!sugar!ficc!peter From: peter@ficc.uu.net (Peter da Silva) Newsgroups: comp.std.c,comp.lang.c Subject: Re: ansi c and directories Message-ID: <7100@ficc.uu.net> Date: 24 Nov 89 21:34:43 GMT References: <13295@s.ms.uky.edu> <20881@mimsy.umd.edu> Reply-To: peter@ficc.uu.net (Peter da Silva) Organization: Xenix Support, FICC Lines: 38 In article <20881@mimsy.umd.edu> chris@mimsy.umd.edu (Chris Torek) writes: > Directory operations would be useful. But so would other things: > `Aye, there's the rub.' Where should they stop? Good question. How about the subset of operations that are available in UNIX, MS-DOS, VMS, VM/whatever...? > An operation to > check the status of another process would be useful. MS-DOS (which > has no processes) would always say `no such process'. This one makes sense, because there's no consensus on what a process is. > Coroutines > (another recurring, ah, thread, in comp.lang.c) would be useful too. This is a hardware independent capability... anything that can implement a useful 'C' can implement coroutines. (counterexamples are left to Henry Spenser... I'm sure he'll come up with one). The lack of prior art is the best defense against this yawning lacuna. > So would standard routines for manipulating the robot arm. (If you > have no robot arm, these simply return an error.) We should not > slight the temperature-and-humidity environment control routines, > either. And then there are the radar missile-detector routines, > and . . . . And these depend on the existance of rare and expensive hardware. Any hosted implementation has a file system. If anyone's interected in the design of a wider "standard" environment, send mail to me and join the C-FUTURES mailing list. Let's fill the gap between ANSI and POSIX. -- `-_-' Peter da Silva . 'U` -------------- +1 713 274 5180. "The basic notion underlying USENET is the flame." -- Chuq Von Rospach, chuq@Apple.COM