From: cziwkga AT ulcc DOT ac DOT uk (Kevin Ashley)
Newsgroups: comp.os.msdos.djgpp
Subject: Re: sbrk ?
Date: 29 Oct 1996 15:11:05 GMT
Organization: University of London Computer Centre
Lines: 52
Distribution: world
Message-ID: <5556q9$96c@calypso.ulcc.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>
Reply-To: k DOT ashley AT ulcc DOT ac DOT uk
NNTP-Posting-Host: silver-e.ulcc.ac.uk
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp


In article <552sj1$ge3 AT sun-cc204 DOT lboro DOT ac DOT uk>, cgjks1 AT lut DOT ac DOT uk (James Soutter) writes:
|>Ulrich Lauther (lauther AT cayley DOT zfe DOT siemens DOT de) wrote:
|>: James Soutter (cgjks1 AT lut DOT ac DOT uk) wrote:
|>: : 
|>: : Excuse my ignorance by why use sbrk().  I thought changing sbrk() was a
|>: : bad idea because it broke the library functions that called malloc().
|>: : 
|>: you didn't read my question. I need it under Visual C++ (which I am
|>: *forced* to use).  I cannot use malloc (at least not conveniently) as
|>: I need memory aligned to 4096 byte boundaries.
|>

Using a simple wrapper to malloc can achieve this, at the cost of
wasting memory - simply allocate what you want + 4096, and pick the
chunk which is 4096-byte aligned. 

|>My question was really about the use of sbrk() rather than your
|>particular situation.
|>
|> 

[ snip ]

||>
|>Does sbrk() work on all UNIX operating systems?  I have always been
|>scared off by the SunOS Manual on sbrk() [quoted below].

sbrk() _works_ on all systems. The warning you quote doesn't say
otherwise. 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:

(1) Give up on sbrk() and find a way to use malloc to do what you want.

(2) Use sbrk() and make sure you do not call any library routines that
     use malloc. The only way to be sure is to look at what routines
     get loaded into the final executable. This course of action may be
      impossible, since malloc() is used so much by standard library
     routines.

(3) Write your own replacement malloc() which co-exists with your use
     of sbrk(). Probably easier than (2), if (1) is a non-starter.
 
-----------------------------------------------------------------------------
Kevin Ashley                              K DOT Ashley AT Ulcc DOT ac DOT uk
Development Manager                http://www.ulcc.ac.uk/staff/Kevin+Ashley
University of London Computer Centre.      ...ukc!ncdlab!K.Ashley
                      This is not a signature