mmap

[Nick Crossley]

In article <12087 at smoke.BRL.MIL> gwyn at brl.arpa (Doug Gwyn) writes:
>Gee, suppose I need N bytes mapped.  I cannot just use N for the `len'
>argument.

SVID Edition 3 is very clear that 'the parameter len need not meet a size
or alignment constraint'.  Any partial page at the end is zero-filled,
and is not written back out to the file if modified.

>SVID3 also seems to say that using an addr of 0 will result
>in a random location in the middle of my process being used, which would
>surely be a horrible design botch; one hopes it means that the necessary
>storage will be allocated from the process's heap, in which case that
>would be the best way to use this function.

Again, SVID 3 is clear: 'When the system selects <an address>, it will
never place a mapping at address zero, nor replace any extant mapping,
nor map into areas considered part of the potential stack or data segments.'
I take this to mean that the default mmap virtual addresses must be far
distant from both stack and sbrk/malloc addresses.  This is not guaranteed,
and is frequently not true, for shmat, which makes it difficult to use
shared memory and malloc extensively in the same program.  I would expect
most systems to use a similar choice of mappings for mmap and shmat, so
in practice, that problem may also disappear.

-- 

<<< standard disclaimers >>>
Nick Crossley, ICL NA, 9801 Muirlands, Irvine, CA 92718-2521, USA 714-458-7282
uunet!ccicpg!ndjc  /  ndjc at ccicpg.UUCP