On 8/20/06, Jason Thorpe <thorpej@shagadelic.org> wrote:
>
> On Aug 20, 2006, at 6:06 AM, Peter Bex wrote:
>
> > The bottom line questions are: is NetBSD correct in implementing
> > SUSv3,
> > if it's incorrect, should it be fixed, and what should Valgrind do in
> > this case?  Should it behave differently on NetBSD than on Linux?
> > After all, a program that worked fine under NetBSD might just fail
> > under any other Unix, if its mmap works differently.
>
> NetBSD's mmap should be fixed.  We should probably version the symbol
> so old programs continue to run, but new programs get the new behavior.
>

From my code reading, please correct me if I am wrong,
It does seem to be the case that when a mmap with length 0 is
specified,size passed to uvm_mmap() can be 0.

In such a case uvm_mmap immediately returns 0, indicating success and
the address is passed back to the calling client, with no actual
allocation performed.
Also, mmap's man page suggests that EINVAL is only returned if length
is < 0 and not 0.
As this case is exposed in our runtime linker, it would be difficult
for valgrind to load any dynamic binaries if this is exposed as an
error.

Does this warrant a PR for ld.elf_so, and possibly other programs in
base that do 0 length mmaps?

Or must valgrind be  taught to accomodate this case in netbsd?

Regards,
Kailash