madvise(2) error returns

[David Schultz]

Are there any objections to changing the madvise(2) interface
slightly such that passing an invalid address range results in
ENOMEM instead of EINVAL?

This has the following advantages:

	- It allows the application to distinguish an invalid
	  address and invalid flags.

	- It is required for compatability with Solaris/Linux/etc.

	- It would make a conformant implementation of
	  posix_madvise(2) simpler, because it would be identical
	  to madvise(2).

The drawback is that applications depending on the old error value
would break.  I think the odds of this are next to nil, since
madvise() is not generally expected to fail for this reason, but I
thought I'd give everyone a chance to prove me wrong or suggest a
better approach.

The patch, sans doc changes, follows.

Index: sys/vm/vm_mmap.c
===================================================================
RCS file: /cvs/src/sys/vm/vm_mmap.c,v
retrieving revision 1.163
diff -u -r1.163 vm_mmap.c
--- sys/vm/vm_mmap.c	4 Jul 2003 12:23:43 -0000	1.163
+++ sys/vm/vm_mmap.c	31 Jul 2003 08:35:56 -0000
@@ -785,9 +785,9 @@
 	map = &td->td_proc->p_vmspace->vm_map;
 	if ((vm_offset_t)uap->addr < vm_map_min(map) ||
 	    (vm_offset_t)uap->addr + uap->len > vm_map_max(map))
-		return (EINVAL);
+		return (ENOMEM);
 	if (((vm_offset_t) uap->addr + uap->len) < (vm_offset_t) uap->addr)
-		return (EINVAL);
+		return (ENOMEM);
 
 	/*
 	 * Since this routine is only advisory, we default to conservative