Path: utzoo!attcan!uunet!wuarchive!brutus.cs.uiuc.edu!uakari.primate.wisc.edu!aplcen!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.unix.wizards
Subject: Re: mmap
Message-ID: <12087@smoke.BRL.MIL>
Date: 7 Feb 90 03:00:05 GMT
References: <22368@adm.BRL.MIL>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 27

In article <22368@adm.BRL.MIL> Kemp@dockmaster.ncsc.mil writes:
> caddr_t mmap( caddr_t addr, int len, int prot, int flags,
>             int fd, off_t off );
> " mmap() establishes a mapping between the process's address space
> at an address paddr for len bytes to the memory object represented
> by fd at off for len bytes.  The value of paddr is an implementation
> dependent function of the parameter addr and the values of flags,
> . . .  A successful mmap() returns paddr as its result."
>What's non-portable about that?

Gee, suppose I need N bytes mapped.  I cannot just use N for the `len'
argument.  What should I use?  Presumably N+{page_size}-1 would suffice,
assuming of course that my application has arranged for addr to point to
that much valid storage.  However, {page_size} is not generally available
to me.  Some *non-POSIX conformant* systems seem to provide a way to
find out via sysconf(PAGESIZE).  (PAGESIZE should not be defined in
<unistd.h>.)  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.

Note also that SVID3 says that -1 is returned on error.  I have no idea
what that means, as -1 is not a caddr_t.  You may recall that we discuss
this sort of botch (as with sbrk()) every so often, and yet here these
idiots go and make the same mistake yet again.  The proper error return
should have been a null pointer.