3

Android ndk-9c seems to be contradicting with the standards on the strerror_r declaration.

Linux man pages show strerror_r declarations as follows:

int strerror_r(int errnum, char *buf, size_t buflen);
        /* XSI-compliant */

char *strerror_r(int errnum, char *buf, size_t buflen);
        /* GNU-specific */

(from: http://linux.die.net/man/3/strerror_r)

And from the following post I understand that there is no proper way to undefine _GNU_SOURCE pragma, (_GNU_SOURCE seems to be defined internally and even if I somehow manage to undefine it I would get other kinds of errors.) which would normally force me to use the GNU-specific version.

why-is-gnu-source-defined-by-default-and-how-to-turn-it-off

The problem is that in android-ndk (version 9c) strerror_r is defined as follows

extern int    strerror_r(int errnum, char *buf, size_t n);

(from: android-ndk-r9c\platforms\android-19\arch-arm\usr\include\string.h line:67)

So even though android ndk defines _GNU_SOURCE, declaration of strerror_r contradict with it. So before I go and start introducing something like 

if (defined(_GNU_SOURCE) && !defined(ANDROID))

to our cross platform project, I want to ask if there is a better way which would let me fix it without touching the code.(maybe some other switch in android that would make strerror_r behave etc.)

Community
  • 1
  • 1
Mert
  • 625
  • 1
  • 4
  • 23
  • Simply don't depend on the returned value? – Some programmer dude Sep 17 '15 at 11:40
  • haha that would be nice actually. the aforementioned project is not my project and it depends on this return value. Not depending on it would still require me touching the code. – Mert Sep 17 '15 at 11:56
  • Have you resolved this problem or found an alternative? – Onur Tuna Jun 28 '16 at 08:26
  • I've touched the code :) Some time later we have removed the dependency on the library that contains this piece of code. The reason I did not want to touch the code at the time was because it was being auto generated(and generator was not ours to begin with). But if you can touch the code the solution is easy – Mert Jun 28 '16 at 08:31
  • I have a gSOAP service and been trying to code a client for it on Android. In iOS version everything worked fine with the stdsoap2.cpp. However when I try the same things on Android it fails. Can you explain a little bit about "touching"? – Onur Tuna Jun 28 '16 at 08:57
  • really there is not much to explain. I've just ignored the return value. – Mert Jun 28 '16 at 10:54

1 Answers1

0

For portability, assume standard behavior (eg XSI) and check for non-standard platforms (eg GNU)

#if !defined(__GLIBC__)
// use the XSI standard behavior.
#else
// assume GNU exception
#endif
Natanael Copa
  • 174
  • 1
  • 4