Unified headers: strerror_r not available

[hrydgard]

Description

Even though I include <string.h>, with unified headers, strerror_r is not available.

FAILED: C:\Android\sdk\ndk-bundle\toolchains\llvm\prebuilt\windows-x86_64\bin\clang++.exe  --target=aarch64-none-linux-android --gcc-toolchain=C:/Android/sdk/ndk-bundle/toolchains/aarch64-linux-android-4.9/prebuilt/windows-x86_64 --sysroot=C:/Android/sdk/ndk-bundle/sysroot  -DARM64 -DMOBILE_DEVICE -DPPSSPP -DSHARED_ZLIB -DUSING_GLES2 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE=1 -D_XOPEN_SOURCE=700 -D_XOPEN_SOURCE_EXTENDED -D__BSD_VISIBLE=1 -D__STDC_CONSTANT_MACROS -I../../../../../ext/native -I../../../../../ -I../../../../../Common -I../../../../../ext/native/ext/rg_etc1 -I../../../../../ext/cityhash -I../../../../../ext/native/ext/libzip -I../../../../../ext/native/ext -I../../../../../ext/libkirk -I../../../../../ext/sfmt19937 -I../../../../../ext/xbrz -I../../../../../ext/xxhash -I../../../../../ext/snappy/. -isystem C:/Android/sdk/ndk-bundle/sources/cxx-stl/gnu-libstdc++/4.9/include -isystem C:/Android/sdk/ndk-bundle/sources/cxx-stl/gnu-libstdc++/4.9/libs/arm64-v8a/include -isystem C:/Android/sdk/ndk-bundle/sources/cxx-stl/gnu-libstdc++/4.9/include/backward -isystem C:/Android/sdk/ndk-bundle/sysroot/usr/include/aarch64-linux-android -D__ANDROID_API__=21 -g -DANDROID -ffunction-sections -funwind-tables -fstack-protector-strong -no-canonical-prefixes -Wa,--noexecstack -Wformat -Werror=format-security  -isystem C:/Android/sdk/ndk-bundle/sysroot/usr/include/aarch64-linux-android -D__ANDROID_API__=21 -g -DANDROID -ffunction-sections -funwind-tables -fstack-protector-strong -no-canonical-prefixes -Wa,--noexecstack -Wformat -Werror=format-security   -std=c++11 -O0 -fno-limit-debug-info -O0 -fno-limit-debug-info  -fPIC   -Wno-multichar -fno-strict-aliasing -include C:/dev/ppsspp/ppsspp_config.h -MD -MT CMakeFiles/Common.dir/Common/Misc.cpp.o -MF CMakeFiles\Common.dir\Common\Misc.cpp.o.d -o CMakeFiles/Common.dir/Common/Misc.cpp.o -c C:\dev\ppsspp\Common\Misc.cpp

C:\dev\ppsspp\Common\Misc.cpp:59:6: error: use of undeclared identifier 'strerror_r'
    if (strerror_r(errCode, err_str, buff_size) == 0) {
        ^

Environment Details

• NDK Version: 14.0.3770861
• Build system: cmake with gradle in Android Studio, cmake -DANDROID_UNIFIED_HEADERS=ON ....
• Host OS: Windows
• Compiler: clang
• ABI: *
• STL: gnustl_static

[DanAlbert]

https://android-review.googlesource.com/c/351830/

[hrydgard]

Thanks!

However, do I understand correctly that the function is only actually there in Android 23+? There's been a call to it in my code for some time in an app built to be compatible with Android 9+, but perhaps it never actually got called - or it would have crashed?

[DanAlbert]

The GNU version of it, yes. There are actually two strerror_r APIs with different signatures, a GNU one and a POSIX one. We've always had the POSIX one, but the GNU one was added in android-23, yes.

You'll get the POSIX one if you are targeting pre-23 or if you don't have _USE_GNU defined (note that this is actually defined by default in C++ mode). You'll get the GNU one if you target 23 or above and have _USE_GNU set.

This restores the old, pre-unified headers behavior, so your app should keep building as it always has once r14b ships.

[hrydgard]

Oh, okay. Thanks for the detailed explanation!

[jmgao]

(Note that if you're only targeting android K or later, you probably don't actually need to use strerror_r. We use a thread local buffer for strerror starting in K)

[hrydgard]

Well, I still keep compatibility with Gingerbread, mostly just because, but also since my app is an excellent fit for the Xperia Play.

But, @jmgao, to me that feels like a move in the wrong direction. Ugly global-state APIs like strerror or strtok should simply be replaced with properly designed threadsafe APIs where the user manages the buffer, IMHO. Inserting thread local buffers behind the users back will only serve to perpetuate these terrible APIs. Though maybe there are pragmatic reasons I'm not thinking of. Anyway, rant over :)

[DanAlbert]

Change is merged.

[enh]

But, @jmgao, to me that feels like a move in the wrong direction.

in general, one advantage TLS has over the _r alternative is that you don't need to know how big a buffer you'll need. if you don't need a copy, no copy is made. if you do, you can size the buffer correctly before copying rather than potentially have to try multiple times or over-allocate.

this is particularly problematic with readdir_r which basically should never be used. (see http://elliotth.blogspot.com/2012/10/how-not-to-use-readdirr3.html for much more on this, including examples of how even the man page screwed up trying to use it.)

[hrydgard]

Well, readdir_r is particularly poorly designed, and readdir has the advantage that there's a DIR* object to stash the pointer to an allocated string in. strerror doesn't have anything like the DIR* and needs a global thread-local pointer, further bloating the TLS libc state.

But I'll concede that if your metric is bugs in user code overall, which is pretty sensible, "non-r" variants have an advantage.