Re: Glibc: _POSIX_MAPPED_FILES & Hurd

[Roland McGrath <roland@frob.com>]

> Hi,
> 
> I have some questions/remarks considering the following change:
> 
> 1998-08-03 16:36  Ulrich Drepper  <drepper@cygnus.com>
> 
> 	* catgets/catgets.c: Use mmap/munmap only is _POSIX_MAPPED_FILES
> 	is defined.
>	[...]
>
> The comment in `unistd.h' says
> 
>    If these symbols are defined, the corresponding features are
>    always available.  If not, they may be available sometimes.
>    The current values can be obtained with `sysconf'.
> 
> So _POSIX_MAPPED_FILES is only defined if mapping of files to memory
> is supported for ALL filesystems.  Thus even if _POSIX_MAPPED_FILES is
> not defined mmap/munmap may work fine in most cases.  For example, on
> the Hurd mmap is not (yet) supported for NFS but is supported for UFS
> and EXT2FS.

The comment is imprecise and misrepresents the POSIX-specified meaning of
the presence or absence of these macros.  The first set of macros listed in
the unstd.h comment (_POSIX_JOB_CONTROL through _POSIX_SELECT, and I
presume the _XOPEN_* and _XBS5_* macros are intended to follow the same
rules, though obviously they are not specified by POSIX) is in 1003.1-1996
Table 2-10 "Compile-Time Symbolic Constants".  The writing is abysmal and
the rationale utterly unhelpful, but the intent is clearly that this set of
symbols is for applications to test at compile-time whether the environment
supports each POSIX Option and hence the application can expect those
headers and library functions at least to be present to compile and link
against.  It then suggests (2.9.3 ll 1610-1613, p 53) that a really anal
application will further query via sysconf at runtime to see if something
indicated to be available at compile-time is in fact not available at
runtime.  Of course, for issues like if mmap will work on a file it ought
to be a pathconf test, and it's not specified that way.  But these macros
aren't really indicating "mapped files" but the presence of the specific
set of Optional functions indicated in the standard.  

It is always permissible for a function to diagnose other errors that are
not specified in the standard, if the cause is outside the scope of the
standard and does not violate other required behavior.  So if mmap fails on
some files because they reside on a filesystem that doesn't support mmap,
that is survivable.  It's the same case as mkfifo failing on a filesystem
that can't represent named pipes.

> Besides, the check is hardly relevant for malloc, since malloc does
> not mmap files if anonymous mapping is supported.  And if anonymous
> mapping is not supported, only `/dev/zero' is mapped, which is likely
> to work even if _POSIX_MAPPED_FILES is undefined.

_POSIX_MAPPED_FILES in fact indicates that the `mmap' function exists at
all, which it might not if neither _POSIX_MAPPED_FILES nor
_POSIX_SHARED_MEMORY_OBJECTS is defined (according to the standard).

> I think it is better to revert the patch, and add
> 
>   CPPFLAGS-malloc.c += -DHAVE_MMAP=0
> 
> to the system dependent Makefiles of those ports that really do not
> support mapping of `/dev/zero'.

No, I think the code is fine as it is.  We just need to update the Hurd's
bits/posix_opt.h to reflect the latest standards and current reality; I'll
commit changes for that soon.