chris@mimsy.UUCP (Chris Torek) (01/11/89)
->In article <225800106@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: ->>some such function [like inkey() or kbhit()] should be a ->>STANDARD C (ANSI C) function .... -In article <310@twwells.uucp> bill@twwells.UUCP (T. William Wells) writes: ->And to repeat what has been said by many: IT CAN'T BE DONE! [in some cases where the rest of the dpANS *can*] In article <84629@sun.uucp> swilson%thetone@Sun.COM (Scott Wilson) writes: -This argument is very similar to one I started some time ago related -to echo/no echo on input, etc. The point of standard libraries is -to smooth over OS dependencies to provide a uniform interface. If -inkey() cannot be provided for on some systems, aren't there other -operations mandated by the Standard that are just as hard to provide? No. -For example, what about the legal modes passed to fopen()? Aren't -there some systems where you simply can't open a file for simultaneous -reading and writing? Or open for writing at the end of a file? What -about fseek(), couldn't that be potentially very inefficient to -implement on some brain-damaged systems? There are a number of systems on which stdio might be fairly slow. As far as I know, however, there are *no* systems (other than standalones) in which it cannot be done at all. But since C runs on IBM machines that see only input screens (collected by 3270s) and on systems with half-duplex ASR 33s, it is easy to see that both get-one-character- without getting-a-line and turn-off-echo are indeed sometimes impossible. -... I guess what I'm wondering is: are there operations -already part of the Standard that are there for historical reasons -(i.e., it has always existed for most implementations) that would be -rejected if it was recommended as a new feature because it was "too -operating system dependent?" Possibly. In fact, malloc() might be one (`too machine dependent'). But most things in the standard can be done everywhere, even on those old IBM systems. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
gwyn@smoke.BRL.MIL (Doug Gwyn ) (01/11/89)
In article <15396@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >Possibly. In fact, malloc() might be one (`too machine dependent'). malloc() can be implemented on all known systems for which a C implementation is otherwise feasible. It might not be able to grow the process allocation at run time, but it can certainly dole out parcels from a pool that was allocated at link time. The stack is also like this on a lot of systems; it needs to be specified large enough at link time. The main operational difference is that malloc() reports failure when it runs out of memory to give away, whereas running out of stack usually has more catastrophic results.
chris@mimsy.UUCP (Chris Torek) (01/11/89)
-In article <15396@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: ->Possibly. In fact, malloc() might be one (`too machine dependent'). In article <9338@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn) writes: -malloc() can be implemented on all known systems for which a C -implementation is otherwise feasible. It might not be able to -grow the process allocation at run time, but it can certainly -dole out parcels from a pool that was allocated at link time. Actually, I was thinking about machines in which different types of objects must come from different address spaces (e.g., all `pointer' objects should be in the range 0x70000000..0x7c000000). -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
desnoyer@Apple.COM (Peter Desnoyers) (01/12/89)
In article <9338@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >In article <15396@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >>Possibly. In fact, malloc() might be one (`too machine dependent'). > I don't think malloc is a problem on most reasonable machines. Brk and sbrk, however, are bad gotchas. If you can allocate memory in any way, you can probably allocate blocks in a way that allows you to construct malloc. However, you may not be able to paste the allocated blocks together to get sbrk semantics. Peter Desnoyers