Guard the GNU strerror_r with an API check.

The deprecated headers have always had only the POSIX definition
available (and it's always been available). With the unified headers
as they are now, we actually make it unavailable for C++ users (C++
implies _GNU_SOURCE) targeting below M. Adding this guard means that
pre-M users will still at least get the POSIX one.

It's not great that moving to M as your target API will actually
change the signature of your strerror_r, but I don't see a better
option here (not until we have the compatibility library, anyway).

Test: make checkbuild
Bug: None
Change-Id: I2d15702467533a826c4ec10fd973ee929d2b562a
This commit is contained in:
Dan Albert 2017-02-14 16:33:06 -08:00
parent 9fc52deab1
commit 8b154b1e82

View file

@ -98,7 +98,7 @@ char* strtok_r(char* __restrict, const char* _Nonnull __restrict, char** _Nonnul
char* strerror(int); char* strerror(int);
char* strerror_l(int, locale_t) __INTRODUCED_IN(23); char* strerror_l(int, locale_t) __INTRODUCED_IN(23);
#if defined(__USE_GNU) #if defined(__USE_GNU) && __ANDROID_API__ >= 23
char* strerror_r(int, char*, size_t) __RENAME(__gnu_strerror_r) __INTRODUCED_IN(23); char* strerror_r(int, char*, size_t) __RENAME(__gnu_strerror_r) __INTRODUCED_IN(23);
#else /* POSIX */ #else /* POSIX */
int strerror_r(int, char*, size_t); int strerror_r(int, char*, size_t);