errno.h constants regression (wasi types vs preprocessor)

[bvibber]

As of cffcd70 the definitions of EPERM etc in errno.h changed from untyped integers to typed references to wasi constants, such as:

#define EPERM              __WASI_ERRNO_PERM
...
#define __WASI_ERRNO_PERM ((__wasi_errno_t)63)

This breaks preprocessor code like this in the dav1d AV1 decoder:

#if EPERM > 0
#define DAV1D_ERR(e) (-(e)) ///< Negate POSIX error code.
#else
#define DAV1D_ERR(e) (e)
#endif

Test case:

#include <stdio.h>
#include <errno.h>

#if EPERM > 0
#endif

int main(int argc, const char **argv) {
    printf("Hello, world\n");
    return 0;
}

Output:

$ emcc -o explode.js explode.c
cache:INFO: generating system asset: is_vanilla.txt... (this will be cached in "/home/brion/.emscripten_cache/is_vanilla.txt" for subsequent builds)
cache:INFO:  - ok
explode.c:4:5: error: token is not a valid binary operator in a preprocessor subexpression
#if EPERM > 0
    ^~~~~
/home/brion/src/emscripten/emscripten/system/lib/libc/musl/arch/emscripten/bits/errno.h:3:28: note: expanded from macro 'EPERM'
#define EPERM              __WASI_ERRNO_PERM
                           ^~~~~~~~~~~~~~~~~
/home/brion/src/emscripten/emscripten/system/include/wasi/api.h:414:44: note: expanded from macro '__WASI_ERRNO_PERM'
#define __WASI_ERRNO_PERM ((__wasi_errno_t)63)
                           ~~~~~~~~~~~~~~~~^
1 error generated.
shared:ERROR: '/home/brion/src/emsdk/upstream/bin/clang -target wasm32-unknown-emscripten -D__EMSCRIPTEN_major__=1 -D__EMSCRIPTEN_minor__=39 -D__EMSCRIPTEN_tiny__=4 -D_LIBCPP_ABI_VERSION=2 -Dunix -D__unix -D__unix__ -Werror=implicit-function-declaration -Xclang -nostdsysteminc -Xclang -isystem/home/brion/src/emscripten/emscripten/system/include/libcxx -Xclang -isystem/home/brion/src/emscripten/emscripten/system/lib/libcxxabi/include -Xclang -isystem/home/brion/src/emscripten/emscripten/system/include/compat -Xclang -isystem/home/brion/src/emscripten/emscripten/system/include -Xclang -isystem/home/brion/src/emscripten/emscripten/system/include/libc -Xclang -isystem/home/brion/src/emscripten/emscripten/system/lib/libc/musl/arch/emscripten -Xclang -isystem/home/brion/src/emscripten/emscripten/system/local/include -DEMSCRIPTEN explode.c -Xclang -isystem/home/brion/src/emscripten/emscripten/system/include/SDL -c -o /tmp/emscripten_temp_LobRc8/explode_0.o -mllvm -combiner-global-alias-analysis=false -mllvm -enable-emscripten-sjlj -mllvm -disable-lsr' failed (1)

[bvibber]

(In a pinch I can work around this by changing dav1d's code to avoid using the #if EPERM > 0 preprocessor comparison, I'm not sure how safe an assumption it was that that should work. Haven't noticed that trick before, but it might be in use elsewhere.)

[bvibber]

Closing this in favor of trying to fix at the dav1d side: https://code.videolan.org/videolan/dav1d/merge_requests/860

[sbc100]

Might be worth raising this on in the WASI repo .. I'm also not how common/valid that pattern is.

[bvibber]

Ok, I'll go ahead and reopen this for further discussion -- is https://github.com/CraneStation/wasi-libc the right repo for that?

[kripken]

Either there or maybe an issue on the main wasi repo, I'm not sure which is better, https://github.com/WebAssembly/WASI

[sbc100]

Yes https://github.com/CraneStation/wasi-libc is the right place.

Lets fix locally at the same time as pushing for an upstream change. @Brion do you have time to whip up a local PR.. along with a simple test i guess?

[bvibber]

@sbc100 sure, I'll work on that shortly. Shouldn't be too hard to add a compilation test.