Date: Mon, 4 Aug 2003 23:06:55 -0700 From: David Schultz <dschultz@OCF.Berkeley.EDU> To: standards@FreeBSD.ORG Subject: madvise(2) error returns Message-ID: <20030805060655.GA818@HAL9000.homeunix.com>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030805060655.GA818>