Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!rpi!netserv2!deven From: deven@rpi.edu (Deven T. Corzine) Newsgroups: comp.sys.amiga.tech Subject: Re: sbrk/brk Message-ID: Date: 28 Mar 90 22:46:41 GMT References: <5457@sugar.hackercorp.com> Organization: Rensselaer Polytechnic Institute, Troy, NY Lines: 76 In-Reply-To: peter@sugar.hackercorp.com's message of 26 Mar 90 15:16:23 GMT On 26 Mar 90 15:16:23 GMT, peter@sugar.hackercorp.com (Peter da Silva) said: Deven> I just looked again. Okay, no problem. sbrk can point to Deven> malloc(), perhaps, or a routine that will call malloc() or Deven> free() appropriately. Peter> Nooooo. sbrk() should point to allocmem, and malloc should call Peter> sbrk. that way you can replace sbrk and have malloc know about Peter> it. Why would I want anyone replacing sbrk()?? It would only be there for compatibility purposes. Malloc() here basically IS AllocMem, except it records the block allocated to be sure it is later freed. There is also an AllocMem function with the same semantics as the Exec AllocMem, but records in the same way. There is no opposite of sbrk(), unless you want to be doing something like sbrk(-1024), which is entirely unclear how it should deal with that. Free the last allocated block if it was 1024 bytes? Ignore it? Error? I see nothing to be gained by having sbrk() call AllocMem() and then have malloc() call sbrk(). If you want it so someone can change sbrk() sensibly... well, they should be changing malloc() instead. People writing for normal Unix don't tend to expect to be changing library functions like that, whether or not they can. What would be the point? Deven> But brk() will have to be dummy-implemented. Peter> Don't implement it at all. It's not universally abailable even Peter> on UNIX. That's another option. Peter> No, that's bcopy and memmov. memcpy doesn't check argument order. Deven> How so? Presumably there is a source and destination... Peter> Yes, but it doesn't check for overlapping moves whether the Peter> sources is before the destination or not. It can be inlined by Peter> a simple loop. So they don't handle overlapping arguments. Well, I want a bcopy() available that DOES handle overlapping arguments. I'm not aiming for perfect compliance with ANY standard. I want something very compatible with V7 Unix with a bunch of ANSI, BSD/SysV, Amiga and other little ditties thrown in. Peter> Someone else will have to point you at Global. I just know the Peter> name. Whatever. Peter> I would recommend providing a traditional division, just for Peter> the sake of programmer sanity. Deven> Logically, sure. Technically, well... they'll likely be mixed Deven> in the actual Exec libraries. Peter> I hope not. What if I want to run something that doesn't use Peter> stdio? (yes, such programs exist, generally in other languages Peter> than C) So what if you do? Do you expect that EVERY program you run will avoid stdio? It will be in a shared library, so it's a one-shot. If one program needs it, then it will be available for any other program at no extra cost. As for stdio specifically, it may or may not be seperated. Likely not. (for various reasons.) Deven -- Deven T. Corzine Internet: deven@rpi.edu, shadow@pawl.rpi.edu Snail: 2151 12th St. Apt. 4, Troy, NY 12180 Phone: (518) 274-0327 Bitnet: deven@rpitsmts, userfxb6@rpitsmts UUCP: uunet!rpi!deven Simple things should be simple and complex things should be possible.