🚀 go-pugleaf

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.