Date: Wed, 21 Jun 2006 13:07:46 -0500 From: Alan Cox <alc@cs.rice.edu> To: John-Mark Gurney <gurney_j@resnet.uoregon.edu> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, Konstantin Belousov <kib@FreeBSD.org>, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/lib/libc/sys mincore.2 src/sys/vm vm_mmap.c Message-ID: <44998AF2.5090600@cs.rice.edu> In-Reply-To: <20060621175821.GB82074@funkthat.com> References: <200606211259.k5LCx5as082227@repoman.freebsd.org> <20060621172849.GA82074@funkthat.com> <44998562.6080705@cs.rice.edu> <20060621175821.GB82074@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
John-Mark Gurney wrote: >Alan Cox wrote this message on Wed, Jun 21, 2006 at 12:44 -0500: > > >>John-Mark Gurney wrote: >> >> >> >>>Konstantin Belousov wrote this message on Wed, Jun 21, 2006 at 12:59 +0000: >>> >>> >>> >>>>Modified files: >>>> lib/libc/sys mincore.2 >>>> sys/vm vm_mmap.c >>>>Log: >>>>Make the mincore(2) return ENOMEM when requested range is not fully >>>>mapped. >>>> >>>> >>>Is this change to be posix compliant or something? ENOMEM seems like >>>the wrong error, or are we allocating memory? >>>#define ENOMEM 12 /* Cannot allocate memory */ >>> >>>the original EINVAL seems to me the correct one, as is commonly used >>>when the data passed in is incorrect... >>> >>> >>I looked at this when the patch was proposed. ENOMEM is the de facto >>standard error for this case. To the best of my knowledge, there is no >>officially-sanctioned specification for mincore(2). >> >> > >Could you please provide a reference to this de facto standard error >as in other places where ENOMEM is used for such an error? > > > I don't understand the question. It is a de facto standard. So, there is no reference, like POSIX or the Open Group that can be cited. Can you restate the question?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44998AF2.5090600>