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
Modify bionic unit tests that are built for glibc so that they also
build against musl. They don't all pass though:
With glibc:
2 SLOW TESTS
4 TIMEOUT TESTS
313 FAILED TESTS
YOU HAVE 2 DISABLED TESTS
With musl:
11 SLOW TESTS
11 TIMEOUT TESTS
363 FAILED TESTS
YOU HAVE 2 DISABLED TESTS
Bug: 190084016
Test: m bionic-unit-tests-glibc with musl
Test: atest bionic-unit-tests-static
Test: atest --host bionic-unit-tests-glibc with glibc
Change-Id: I79b6eab04fed3cc4392450df5eef2579412edfe1
Mostly from extra test cases, but also:
* Move the fgets size < 0 assertion into fgets.
* Use ELF aliases for strtoq/strtouq rather than duplicating code.
* Don't check uname() succeeded, since it can't fail.
Test: treehugger
Change-Id: I2e6b3b88b0a3eb16bd68be68b9bc9f40d8043291
This adds a new mechanism to say "replace struct S with #include <bits/S.h>".
Also switch epoll_event over to the new mechanism.
Also use the kernel's struct sockaddr_storage directly rather than behind
an unnecessary #define.
This patch also removes some dead code in the header scrubber. This code
still needs rewriting completely. I learned that a "block" isn't necessarily
a single struct definition, say; it might be a run of them. It seems like
a block is a run of preprocessor directives or a run of regular code.
Bug: https://issuetracker.google.com/36987220
Test: new test
Change-Id: Ic6a5c09559766a4babe3cd4c3ea538b885e07308
Also, for the stuff that's also in <netinet/in.h> as real functions,
check that they're there too (and as functions rather than macros,
since that was historically not true).
Bug: http://b/28432448
Test: ran tests
Change-Id: I7e4ae926f7e02de3b6dd38d1953e5b3b43d44f74
