peter@sugar.hackercorp.com (Peter da Silva) (03/26/90)
> I just looked again. Okay, no problem. sbrk can point to malloc(), > perhaps, or a routine that will call malloc() or free() appropriately. Nooooo. sbrk() should point to allocmem, and malloc should call sbrk. that way you can replace sbrk and have malloc know about it. > But brk() will have to be dummy-implemented. Don't implement it at all. It's not universally abailable even on UNIX. > Peter> No, that's bcopy and memmov. memcpy doesn't check argument order. > How so? Presumably there is a source and destination... Yes, but it doesn't check for overlapping moves whether the sources is before the destination or not. It can be inlined by a simple loop. Someone else will have to point you at Global. I just know the name. Peter> I would recommend providing a traditional division, just for Peter> the sake of programmer sanity. > Logically, sure. Technically, well... they'll likely be mixed in the > actual Exec libraries. I hope not. What if I want to run something that doesn't use stdio? (yes, such programs exist, generally in other languages than C) -- _--_|\ Peter da Silva <peter@sugar.hackercorp.com>. / \ \_.--._/ I haven't lost my mind, it's backed up on tape somewhere! v "Have you hugged your wolf today?" `-_-'
deven@rpi.edu (Deven T. Corzine) (03/29/90)
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.
peter@sugar.hackercorp.com (Peter da Silva) (03/29/90)
(lowers thermostat 5 degrees) In article <DEVEN.90Mar28174710@netserv2.rpi.edu> deven@rpi.edu (Deven T. Corzine) writes: > 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? Do anything you want. Negative sbrks are no longer widely supported. > 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. You're right, that was a silly argument. On the other hand, people do like to change malloc around. Fancy mallocs exist and *they* call sbrk. If sbrk then turns around and calls malloc you're going to have, well, funny interactions. > 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. Which is what memmov() is for, so alias it to memmov(). > I'm not aiming for > perfect compliance with ANY standard. But if you can get better compliance cheaply, why not? > 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. That depends on how the interface library is set up. If it's set up so you can pick and choose your stubs that's fine. -- _--_|\ Peter da Silva <peter@sugar.hackercorp.com>. / \ \_.--._/ I haven't lost my mind, it's backed up on tape somewhere! v "Have you hugged your wolf today?" `-_-'