From: cgjks1 AT lut DOT ac DOT uk (James Soutter)
Newsgroups: comp.os.msdos.djgpp
Subject: Re: sbrk ?
Date: 29 Oct 1996 17:40:20 GMT
Organization: Loughborough University, UK.
Lines: 61
Distribution: world
Message-ID: <555fi4$odm@sun-cc204.lboro.ac.uk>
References: <54qkhh$j8h AT salomon DOT mchp DOT siemens DOT de> <54s77r$phg AT sun-cc204 DOT lboro DOT ac DOT uk> <54se3i$ifp AT salomon DOT mchp DOT siemens DOT de> <552sj1$ge3 AT sun-cc204 DOT lboro DOT ac DOT uk> <5556q9$96c AT calypso DOT ulcc DOT ac DOT uk>
NNTP-Posting-Host: cgneiss.lut.ac.uk
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

James Soutter (cgjks1 AT lut DOT ac DOT uk) wrote:

: I have tried SunOS and Linux and mmap'ing /dev/zero works.  Solaris is
: probably also ok because it is designed to be some what compatibility
: with SunOS but I don't have access to a Solaris box.

: HP-UX does not have a "/dev/zero".  Weird operating system.

Scratch that.

SunOS and Linux and Solaris (I found a box) all allow /dev/zero to
be mapped to create an "unnamed memory region".

HP-UX allows an "unnamed memory region" to be created by passing the
flag "MAP_ANOYMOUS" to mmap.  Is this a SysV thing?  Oh well, I guess
it saves a file descriptor.

Anyway, here is the UNIX code to allocate a page of memory:

#ifdef hpux
        newSpace = mmap((caddr_t) 0, getpagesize(), PROT_READ | PROT_WRITE,
                        MAP_ANONYMOUS | MAP_VARIABLE | MAP_PRIVATE,
                        -1, 0);
#else
        newSpace = mmap((caddr_t) 0, sysconf(_SC_PAGE_SIZE),
                        PROT_READ | PROT_WRITE,
                        MAP_PRIVATE, devZeroFile, (off_t) 0);
#endif


Kevin Ashley (cziwkga AT ulcc DOT ac DOT uk) wrote:

: ... The problem is that sbrk() is a primitive, low-level interface
: for expanding your address space, and it only works effectively if
: all its callers cooperate with each other, or at least understand each
: other's behaviour. standard malloc() assumes it is the sole user of sbrk().
: It breaks if this is not the case. You have three courses of action that
: I can see:

: (3) Write your own replacement malloc() which co-exists with your use
:      of sbrk(). Probably easier than (2), if (1) is a non-starter.

Would that work.  I thought the library functions would end up calling
library malloc() and your functions would call your malloc().

Anyway, here is one more idea.  It might work under DOS.

(4) Malloc is assumed to call sbrk().  Malloc will call sbrk() when it
    doesn't have enough memory.  So mallocing 4096 bytes will probably
    call sbrk().  Test this by using realloc() to add an extra memory.
    If it doesn't move then sbrk() is probably being called.
    
    If no library functions call malloc() then realloc works some what
    like sbrk().  If you realloc() the block of memory at the end of the
    heap then realloc() has to call sbrk() and can be used as a substitute
    for sbrk().
    
    
-- James