🚀 go-pugleaf

(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?" `-_-'