Re: [PATCH] Fix wordsize-32 mmap offset for negative value (BZ#18877)

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

On 20-01-2016 19:44, Joseph Myers wrote:
> I'm looking at failures of this new test for MIPS, but am puzzled by the 
> descriptions of this issue in terms of things being incorrect and fixed 
> without any statement of what is actually correct or why that is correct.
> 
> The expectation in the test seems to be that negative offsets passed to 
> mmap should be interpreted as large unsigned values.  But I can't find 
> anything in POSIX, or in the glibc manual, or in the Linux man-pages 
> collection, to justify those semantics.  So what is the basis for that 
> interpretation as part of the glibc API (and for its being compatible with 
> POSIX), rather than negative arguments being considered invalid?
> 

You are correct, I bluntly used the bz report testcase as the one for the
patch.  And checking both Linux and POSIX negative offset are not really
specified, so the issue at BZ#18877 can't really being considered a regression
since the offset usage is undefined behaviour.  The fix itself on the
wordsize-32 I still consider valid since it was using a shift arithmetic
signed is implementation-defined behaviour (and the divide operation is
assumed to not be implementation-defined).

About the test I think we should just remove it and state that invalid
offsets are undefined or architecture define.

> (The MIPS mmap syscall uses a signed argument and does a signed arithmetic 
> shift on it, meaning that matching the MIPS semantics to other 
> architectures will involve using mmap2 for o32 and making mmap not an 
> alias for mmap64 for n32 because mmap for n32 will need to zero-extend its 
> offset argument before calling the syscall.)

I think this can be a future cleanup to simplify implementations.