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

diff --git a/libc/include/string.h b/libc/include/string.h
index 16fc4b6..7611b80 100644 (file)
--- a/libc/include/string.h
+++ b/libc/include/string.h
@@ -98,7 +98,7 @@ char* strtok_r(char* __restrict, const char* _Nonnull __restrict, char** _Nonnul
 
 char* strerror(int);
 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);
 #else /* POSIX */
 int strerror_r(int, char*, size_t);