Mail Archives: djgpp/1996/10/28/16:48:44
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.
My question was really about the use of sbrk() rather than your
particular situation.
: : In DJGPP, why not just use "__dpmi_allocate_memory" to allocate new
: : memory for the memory manager (I havn't tried this). Similarly under
: : UNIX, why not just use mmap on /dev/zero to allocate memory (it works
: : for me).
:
: all UNIXes? (Need SunOS, Solaris, Linux, HP-UX).
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.
Does sbrk() work on all UNIX operating systems? I have always been
scared off by the SunOS Manual on sbrk() [quoted below]. The HP-UX
manual says something similar but the language is not as strong.
> WARNINGS
> Programs combining the brk() and sbrk() system calls and
> malloc() will not work. Many library routines use malloc()
> internally, so use brk() and sbrk() only when you know that
> malloc() definitely will not be used by any library routine.
-- James
- Raw text -