Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

-wpedantic reports erroneous warning for parameters in EM_ASM_ blocks #7113

Closed
aaron-michaux opened this issue Sep 11, 2018 · 5 comments
Closed
Labels

Comments

@aaron-michaux
Copy link

Compiling the following code should work without warning. Even in pedantic mode.

#include <emscripten.h>

int main(int, char * *)
{
    int x = EM_ASM_INT({
            console.log('I received: ' + $0);
            return $0 + 1;
        }, 100);
    printf("%d\n", x);
    return 0;
}

However, emcc reports the following warning:

~ > emcc --version
emcc (Emscripten gcc/clang-like replacement) 1.38.8 (commit 1c100d9f8ad4e073b33d64aed2fdf91cbc355cb3)

~ > emcc -x c++ -std=c++17 -stdlib=libc++ -DTARGET="ariel.html" -Wall -Wextra -Wpedantic test.cpp 
test.cpp:7:42: warning: '$' in identifier [-Wdollar-in-identifier-extension]
            console.log('I received: ' + $0);
                                         ^
test.cpp:8:20: warning: '$' in identifier [-Wdollar-in-identifier-extension]
            return $0 + 1;
                   ^
2 warnings generated.
@kripken
Copy link
Member

kripken commented Sep 12, 2018

This is probably a side effect of how EM_ASM works - the C compiler does see that code. To avoid that, we'd need to do preprocessing ourselves before clang, which is trickier. But maybe there's another solution I'm missing.

@aaron-michaux
Copy link
Author

I'm not sure of the moving parts, but maybe the $0 variable can be mangled as it is written out? Regardless, using the -Wno-dollar-in-identifier-extension switch turns off the warning, so perhaps the entire issue is -pedentic =).

@kripken
Copy link
Member

kripken commented Sep 13, 2018

Yeah, but mangling the $0 would need to be done before clang sees it - which would be a big change, I'm afraid.

Another option is to not use $N for those arguments, it could be _N for example. That would be a breaking change, unless we supported both - so none of the options is very appealing, sadly.

@aaron-michaux
Copy link
Author

Suppose it would cause other problems with emcc supported both $N and _N. I think a lot of people use _ at the beginning of their variable names even though I believe it is reserved. Maybe __arg_N would be more obvious. I'm not sure I should be making a recommendation, but those are my thoughts.

@stale
Copy link

stale bot commented Sep 18, 2019

This issue has been automatically marked as stale because there has been no activity in the past year. It will be closed automatically if no further activity occurs in the next 7 days. Feel free to re-open at any time if this issue is still relevant.

@stale stale bot added the wontfix label Sep 18, 2019
@stale stale bot closed this as completed Sep 25, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants