Instead of the hardcoded PAGE_SIZE 4096 macro, use the
real system page-size as queried from the auxillary vector.
Bug: 277272383
Bug: 300367402
Test: atest -c bionic-unit-tests
Change-Id: I2f1ad1b431e36ef45e9f53f713ced6b06e0d4f70
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
The close_range() test in particular has been confusing a lot of
partners. I think the sys_epoll_test.cpp idiom is the clearest of the
ones in use, so let's use that everywhere. (I haven't actually touched
the SysV IPC tests, because if we do touch them, _deleting_ them --
since all those syscalls are not allowed on Android -- is probably the
change to be made!)
I'm on the fence about factoring this idiom out into a macro. There
should never be too many of these, and we should probably be removing
them? Is anyone still running the current bionic tests on 4.3 kernels
without membarrier(2), and if they are --- why?!
For now though, I haven't removed any of our existing tests; I've just
moved them over to the sys_epoll_test.cpp style.
Test: treehugger
Change-Id: Ie69a0bb8f416c79957188e187610ff8a3c4d1e8f
We've talked about this many times in the past, but partners struggle to
understand "expected 38, got 22" in these contexts, and I always have to
go and check the header files just to be sure I'm sure.
I actually think the glibc geterrorname_np() function (which would
return "ENOSYS" rather than "Function not implemented") would be more
helpful, but I'll have to go and implement that first, and then come
back.
Being forced to go through all our errno assertions did also make me
want to use a more consistent style for our ENOSYS assertions in
particular --- there's a particularly readable idiom, and I'll also come
back and move more of those checks to the most readable idiom.
I've added a few missing `errno = 0`s before tests, and removed a few
stray `errno = 0`s from tests that don't actually make assertions about
errno, since I had to look at every single reference to errno anyway.
Test: treehugger
Change-Id: Iba7c56f2adc30288c3e00ade106635e515e88179
These are old enough now that the latest devices will have kernels that
support them.
Also add basic doc comments to <sys/mman.h>.
Test: treehugger
Change-Id: I1b5ff5db0b6270f5c374287cac1d6a751a0259f5
(Where errno is relevant.)
Also consistently use -1 as the fd for anonymous mmaps. (It doesn't matter,
but it's more common, and potentially more intention-revealing.)
Bug: http://b/65608572
Test: ran tests
Change-Id: Ie9a207632d8242f42086ba3ca862519014c3c102
This removes another way to obtain objects larger than PTRDIFF_MAX. The
only known remaining hole is now jemalloc's merging of virtual memory
spans.
Technically this could be wrapped in an __LP64__ ifndef since it can't
occur on 64-bit due to the 1:1 split. It doesn't really matter either
way.
Change-Id: Iab2af242b775bc98a59421994d87aca0433215bd
The mremap definition was incorrect (unsigned long instead of int) and
it was missing the optional new_address parameter.
Change-Id: Ib9d0675aaa098c21617cedc9b2b8cf267be3aec4
Remove the incorrect tests that use a negative offset for mmap without
a fd.
Add a small set of tests for mmap.
Bug: 15436969
Change-Id: Id537d33cd4cdc26dee6cdfa9bf9cf35754bce335
We don't actually need to worry about sign extension if we reject
negative values ourselves. Previously it was possible to come up
with negative but aligned values that we would pass to the kernel;
in the case of mmap (as opposed to mmap64) we'd incorrectly turn
those into large positive offsets.
Change-Id: I2aa583e0f892d59bb77429aea8730b72db32dcb0
