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:
parent
9fc52deab1
commit
8b154b1e82
1 changed files with 1 additions and 1 deletions
|
@ -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);
|
||||
|
|
Loading…
Reference in a new issue