🚀 go-pugleaf

On 25 Mar 90 15:18:05 GMT, peter@sugar.hackercorp.com (Peter da Silva) said:

Peter> Sbrk really has the same semantics as AllocMem. On segmented
Peter> machines it's happy to allocate memory segments and give you
Peter> memory in chunks that aren't contiguous with each other. You
Peter> would be quite justified in making sbrk a dummy front end for
Peter> AllocMem().

I just looked again.  Okay, no problem.  sbrk can point to malloc(),
perhaps, or a routine that will call malloc() or free() appropriately.
But brk() will have to be dummy-implemented.

Peter> No, that's bcopy and memmov. memcpy doesn't check argument order.

How so?  Presumably there is a source and destination...

Deven> One problem I have is that I don't have any really good
Deven> reference for ANSI library functions...

Peter> You can get the draft standard from Global Engineering Documents.

I do have friends with K&Rv2, but I don't know how accurate it is.
What is Global Engineering Documents?

Deven> As for library calls vs. system calls, the division may not be
Deven> the traditional ones.

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.

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.