Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!mephisto!udel!rochester!rit!cci632!ccicpg!hobbit!ndjc
From: ndjc@hobbit.UUCP (Nick Crossley)
Newsgroups: comp.unix.wizards
Subject: Re: mmap
Summary: len does not have to be page multiple
Message-ID: <57255@hobbit.UUCP>
Date: 9 Feb 90 02:20:15 GMT
References: <22368@adm.BRL.MIL> <12087@smoke.BRL.MIL>
Reply-To: ndjc@ccicpg.UUCP (Nick Crossley)
Organization: ICL North America, Irvine, CA 92718
Lines: 29

In article <12087@smoke.BRL.MIL> gwyn@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@ccicpg.UUCP